给众大师所提倡的代码风格唱唱反调

现在已经有两个这样的论断似已成为共识:

1 简短的不重复的代码就一定强过啰嗦的代码。
2 声明式代码一定强于命令式代码。

很可惜,这两个论断,在我看来,在不少的场合都不成立,反对的方式也很明确:

1 简短的不重复的代码不一定比啰嗦的代码易懂。
2 声明式代码也未必就比命令式代码易懂。

这里用来反对这两个论断的是我称之为最高原则的“易懂”。

“简短不重复”很容易与“易懂”发生冲突,比如一些大公司的产品说明书,要求高到仅仅识字的人就能够看懂,这导致一些啰嗦,重复的说法。如果要求是用最简短的话将功能做一说明,内文到处是引用参见,像形式系统一样严密,估计能看懂的也就没几个人了。

适当的啰嗦,实际上,对提高易懂程度起到的是很正面的作用。

人脑的思维方式很大程度上就是命令式的,大脑很很容易的记住一个过程,但很难进行多变量的逻辑推理和数学计算。对声明式风格的强加运用,带来编码难度的大大提高,也也就是为什么lisp虽然在范式上大大超越各种编程语言,却一直没有进入软件工业的主流。

有人肯定要提出强烈的反对意见,例如在面向变化和重构方面,命令式代码一直就面临难题,是的,很大程度上是因为现有软件生产力工具的局限,才导致了这样一个局面,而上述的两个原则,只是软件灵活性增强逼得大家不得不想出来的一个权宜之计,也谈不上是解决问题的灵丹妙药。

易懂要看对象的,对一个不懂编程的人来说,再易懂的代码也不懂了。

更重要的是,良好的代码风格(当然包括你引用的两个原则)不仅仅带来易懂,更带来灵活和可维护性。

这个要灵活处理吧。不是说你写的短就好,或者说你写的越规范越好。
有时候要在整洁,美观和性能上面找一个平衡点。

我就发现了,有时我把代码写的很简,运行的效率的确快了很多,但是在可读性上,就差了很多。这个时候,就只有通过补充注释来弥补。

从生产业务角度来说。我不排斥代码风格,但我们应该过多关注性能和效率。灵活使用注释。可能会减少代码不够清晰带来的困惑。

理论是死的,人是活的

很同意 netroby 和 pangbuddy ,这其实是人脑和电脑的区别,找个平衡点就好

"D. Hilbert曾经说过:如果随便在大街上找一个人,你能对他说明白你现在正在做的数学,那么你做的数学才是好的数学。H. Wyle曾经回忆说:在哥廷根,Hilbert就像一个吹笛人,他优美的笛声使得我们这些老鼠都跳到了数学的大河里。"

我支持uda1341的“易懂”原则,只有可读性好的代码,才可能被理解,才可能被复用,有了复用才能真正体现效率与灵活。

“易懂”不是代码写的越少越好,而是保持代码的“清晰、一致”,不言自明。如果你会Java语言(不止语法,你会英语语法,就会英语了吗?),就应该读得懂java代码,否则有可能就是这段java代码写得不好;如果你懂汉语,就应该读得懂“易懂”的汉语文章,否则可能就是你缺乏了必要的生活阅历。

netroby的所谓的运行效率与性能,是从微观层面或运行的角度看;而可读性是从宏观层面或开发的效率看。这两个在极个别的情况下可能会出现冲突,但是绝大多数时候应该还是相辅相成的,也就是并不矛盾。

可读性,可以作为代码本身衡量的最高原则之一,甚至没有之一。

的确,可以说是最高准则,这本来就是程序语言的本来出发点。

但可读性也有程度一说,也就是到什么样程度的易读就满足了呢?单单一个易读性一词,并没有说出这一点。

netroby当中就说到了注释,人思维方式不一样,导致代码有些简短有些很长(有些人因为某些代码写多了,经过精细琢磨后,得出了一种对于有经验的人来说是一种易懂而且有效的写法),所以这时需要注释来弥补。

所以单就易读性,还有程度需要考量。


抱歉,这个例子涉及到版权问题,全文删除,保留链接:

http://www.javaeye.com/topic/841196
[该贴被uda1341于2010-12-19 02:06修改过]