这两天,逛了逛gitee。

和github比,还是有惊喜的,打开速度快,完全不存在github那样动不动“查无此人”的情况。 整体氛围还算是比较活跃,开源项目众多,其中的精品也有不少。

有了这个gitee,咱们也算是在开源界有了一块自留地,如果再有卡脖子的情况,大约不会束手无策了。

不过,从源代码的种类和用途来看,gitee还是不如github覆盖面那么广的。 在某些小众领域,开源项目数量少,质量也不高,比如cad插件相关的代码,就是这方面的典型。

典型案例

在gitee上,搜索“cad+lisp”,只能找到12个项目,这里边,还有若干个实际上不相关的项目。 其中,最受欢迎的项目,是一个叫做AutoLispBaseFunctionLibrary的。

那么,这个项目到底是做什么的呢?

从它的名称来看,应该就是一个函数库。从它的介绍来看,也确实如此。它的介绍里边说,这个项目是搜集、整理各种现有代码而来的。 某种程度上来讲,和晓东的函数库差不多,只是,它这个项目某些代码可能并没有获得作者的发布授权。

从它的介绍和源代码来看,这个项目的创建者确实如他(她)所说,在尽力搜集整理各种源代码。

说他(她)在整理源代码,是因为readme.md的几乎90%的篇幅,都在谈代码风格。 尽管代码风格的相关内容,也是从所谓的google的lisp风格指南摘抄而来的, 但是,已经能说明创建者确实在关注代码风格问题,也在做一些事情,试图统一风格。 毕竟,网络上的各种cad插件源代码,大部分都可以用乱七八糟来形容,完全没有风格可言。

代码风格怪异

然而,十分遗憾的是,正是这个长篇大论的代码风格文字,暴露了致命问题。

代码风格趋近于c语言,与lisp主流风格背道而驰

尽管列举了好代码与坏代码的例子,创建者自己却并没有按照好代码的写法来写, 反倒是推荐采用飞诗lisp编辑器!

飞诗lisp编辑器的代码风格,是典型的c语言的风格,其特点是尾括号另起一行。 尽管autocad官方的visual lisp ide,也是拿这种风格作为默认设置, 但是,这种做法在lisp世界中,却属于妥妥的歪门邪道。 而那篇所谓的google的lisp风格指南,也是明确要求不得采用这种风格的!

强行要求函数名禁用斜线分隔符

诚然,lisp的传统习惯就是使用减号作分隔符,不管函数名还是变量名,单词之间都是采用减号分隔符。 然而,采用其他符号作为分隔符,尽管不常见,也不是没有的,况且,语言本身就是支持的。

就连emacs这样具有无比号召力的软件,也有若干个高质量、非常受欢迎的插件,使用的是斜线分隔符的,比如org插件。

所以,这里的问题就是,你可以不提倡不建议,但是不能禁止。连语言本身都支持的做法,你又有什么资格去禁止呢?

写代码不老实

无形参的函数非要把括号写作nil

比如,无形参的函数,一般写作下面这样:

1
2
(defun foo () 
  (do something))

他(她)偏要写作这样:

1
2
(defun foo nil 
  (do something))

还偏偏说,这是在学习模仿某名人的写法,是在向人家致敬!

好吧。这么写确实可以正常运行。因为,上述代码在送到interpreter之后,eval一番下来, ()就是等于nil,这门编程语言确实就是这么定义()的。

只是,这么做有什么意义呢?让人困惑,给读代码带来不便,这不是自个儿坑自个儿吗?

函数体的语句非要加上eval

比如,获取acad根对象,自定义函数一般写作下面这样:

1
2
(defun acad-object () 
  (vlax-get-acad-object))

他(她)偏要写作这样:

1
2
3
4
(defun BF-acad-object nil
	(eval (list 'defun 'BF-acad-object 'nil (vlax-get-acad-object)))
	(BF-acad-object)
)

这是嫌interpreter的执行速度太快,人为增加一层eval,让她的脚步慢一点?

就算是要用eval实现多态,也不是这样子的用法啊,就获取一个acad对象,不至于啊!

结语

管中窥豹,可见一斑。

就是这样子的一个项目,在gitee上拿到了23星、19个fork,在cad插件领域算是目前最为流行的项目, 代码就是这个样子的,不能不令人感到遗憾。

不过,稍稍欣慰的是,还有若干个cad插件项目,代码质量显著地高于这个最流行的项目, 尽管它们并不是那么受欢迎。