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

10-12-05 uda1341
现在已经有两个这样的论断似已成为共识:

1 简短的不重复的代码就一定强过啰嗦的代码。

2 声明式代码一定强于命令式代码。

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

1 简短的不重复的代码不一定比啰嗦的代码易懂。

2 声明式代码也未必就比命令式代码易懂。

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

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

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

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

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

    

niyunjiu
2010-12-06 20:04
易懂要看对象的,对一个不懂编程的人来说,再易懂的代码也不懂了。

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

netroby
2010-12-07 17:15
这个要灵活处理吧。不是说你写的短就好,或者说你写的越规范越好。

有时候要在整洁,美观和性能上面找一个平衡点。

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

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

pangbuddy
2010-12-07 19:22
理论是死的,人是活的

SpeedVan
2010-12-07 21:34
很同意 netroby 和 pangbuddy ,这其实是人脑和电脑的区别,找个平衡点就好

猜你喜欢
2Go 1 2 下一页