http://blog.sina.com.cn/s/blog_5d90e82f0101j529.html
很早就想写这样一篇博文了,可是一直没来得及动笔。在学校的时候,时间似乎总是不够用,因为一旦有点时间,你就想是不是该用来多看点论文。所以我很高兴,工作的生活给了我真正自由的时间,让我可以多分享一些自己的经验。
我今天想开始写这系列文章的原因是,很多程序员的头脑中都有一些通过“非理性”方式得到的错误观点。这些观点如此之深,以至于你没法跟他们讲清楚。即使讲清楚了,一般来说也很难改变他们的习惯。
程序员的世界,是一个“以傲服人”的世界,而不是一个理性的,“以德服人”的世界。很多人喜欢在程序里耍一些“小聪明”,以显示自己的与众不同。由于这些人的名气和威望,人们对这些小聪明往往不加思索的吸收,以至于不知不觉学会了很多表面上聪明,其实导致不必要麻烦的思想,根深蒂固,难以去除。接着,他们又通过自己的“傲气”,把这些错误的思想传播给下一代的程序员,从而导致恶性循环。人们总是说“聪明反被聪明误”,程序员的世界里,为这样的“小聪明”所栽的根头,可真是数不胜数。以至于直到今天,我们仍然在疲于弥补前人所犯下的错误。
所以从今天开始,我打算陆续把自己对这些“小聪明”的看法记录在这里,希望看了的人能够发现自己头脑里潜移默化的错误,真正提高代码的“境界”。可能一下子难以记录所有这类误区,不过就这样先开个头吧。
小聪明1:片面追求“短小”
我经常以自己写“非常短小”的代码为豪。有一些人听了之后很赞赏,然后说他也很喜欢写短小的代码,接着就开始说 C 语言其实有很多巧妙的设计,可以让代码变得非常短小。然后我才发现,这些人所谓的“短小”跟我所说的“短小”,完全不是一回事。
我的程序的“短小”,是建立在语义明确,概念清晰的基础上的。在此基础上,我力求去掉冗余的,绕弯子的,混淆的代码,让程序更加直接,更加高效的表达我心中设想的“模型”。这是一种在概念级别的优化,而程序的短小精悍只是它的一种“表象”。这种短小,往往是在“语义” (semantics) 层面的,而不是在“语法”层面死抠几行代码。我绝不会为了程序“显得短小”而让它变得难以理解,或者容易出错。
相反,很多其它人所追求的“短小”,却是盲目的,没有原则的。在很多时候,这些小伎俩都只是在“语法” (syntax) 层面,比如,想办法把两行代码写成一行。可以说,这种“片面追求短小”的错误倾向,造就了一批语言设计上的错误,以及一批“擅长于”使用这些错误的程序员。
举一个简单的例子,就是很多语言里都有的 i++ 和 ++i 这两个“自增”操作(下文合称“++操作”。很多人喜欢在代码里使用这两个东西,因为这样可以“节省一行代码”。殊不知,节省掉的那区区几行代码,比起由此带来的混淆和错误,其实是九牛之一毛。
从理论上讲,++操作本身就是错误的设计。因为它们把对变量的“读”和“写”两种根本不同的操作,毫无原则的合并在一起。这种对读写操作的混淆不清,带来了非常难以发现的错误,甚至在某些时候带来效率的低下。
相反,一种等价的,“笨”一点的写法,i = i + 1,不但更易理解,而且更符合程序内在的一种精妙的“哲学”原理。这个原理,其实来自一句古老的谚语:你不能踏进同一条河流两次。也就是说,当你第二次踏进“这条河”的时候,它已经不再是之前的那条河!这听起来有点玄,但是我希望能够用一段话解释清楚它跟 i = i + 1 的关系:
现在来想象一下你拥有明察秋毫的“写轮眼”,能看到处理器的每一步微小的操作,每一个电子的流动。现在对你来说,i = i + 1 的含义是,让 i 和 1 进入“加法器”。i 和 1 所含有的信息,以 bit 为大小,被加法器的线路分解,组合。经过一番复杂的转换之后,在加法器的“输出端”,形成一个“新”的整数,它的值比 i 要大 1。接着,这个新的整数通过电子线路,被传送到“另一个”变量,这个变量的名字,“碰巧”也叫做 i。特别注意我加了引号的词,你是否能用头脑想象出线路里面信息的流动?
我是在告诉你,i = i + 1 里面的第一个 i 跟第二个 i,其实是两个完全不同的变量——它们只不过名字相同而已!如果你把它们换个名字,就可以写成 i2 = i1 + 1。当然,你需要把这条语句之后的所有的 i 全都换成 i2(直到 i 再次被“赋值”)。这样变换之后,程序的语义不会发生改变。
我是在说废话吗?这样把名字换来换去有什么意义呢?如果你了解编译器的设计,就会发现,其实我刚刚告诉你的哲学思想,足以让你“重新发明”出一种先进的编译器技术,叫做 SSA(static single assignment)。我只是通过这个简单的例子让你意识到,++操作不但带来了程序的混淆,而且延缓甚至阻碍了人们发明像 SSA 这样的技术。如果人们早一点从本质上意识到 i = i + 1 的含义(其实里面的两个 i 是完全不同的变量),那么 SSA 可能会提前很多年被发明出来。
(好了,到这里我承认,想用一段话讲清楚这个问题的企图,失败了。)
所以,有些人很在乎 i++ 与 ++i 的区别,去追究 (i++) + (++i) 这类表达式的含义,追究 i++ 与 ++i 谁的效率更高,…… 其实都是徒劳的。“精通”这些细微的问题,并不能让你成为一个好的程序员。真正正确的做法其实是:完全不使用 i++ 或者 ++i。
当然由于人们约定俗成的习惯,在某种非常固定,非常简单,众人皆知的“模式”下,你还是可以使用 i++ 和 ++i。比如: for (int i=0; i < n; i++)。
但是除此之外,最好不要在任何其它地方使用。特别不要把 ++ 放在表达式中间,或者函数的参数位置,比如 a[i++], f(++i) 等等,因为那样程序就会变得难以理解,容易出错。如果你把两个以上的 ++ 放在同一个表达式里,就会造成“非确定性”的错误。这种错误会造成程序可能在不同的编译器下出现不同的结果。
虽然我对这些都了解的非常清楚,但我不想继续探讨这些问题。因为与其记住这些,不如完全忘记 i++ 和 ++i 的存在。
好了,一个小小的例子,也许已经让你意识到了片面追求短小程序所带来的巨大代价。很可惜的是,程序语言的设计者们仍然在继续为此犯下类似的错误。一些“新”的语言,设计了很多类似的,旨在“缩短代码”,“减少打字量”的雕虫小技。也许有一天你会发现,这些雕虫小技所带来的,除了短暂的兴奋,剩下的就是无尽的烦恼。
思考题:
1. Google 公司的代码规范里面规定,在任何情况下 for 语句和 if 语句之后必须写花括号,即使 C 和 Java 允许你在其只包含一行代码的时候省略它们。比如,你不能这样写
for (int i=0; i < n; i++)
而必须写成
for (int i=0; i < n; i++) {
}
请分析:这样多写两个花括号,是好还是不好?
(提示,Google 的代码规范在这一点上是正确的。为什么?)
2. 当我第二次到 Google 实习的时候,发现我一年前给他们写的代码,很多被调整了结构。几乎所有如下结构的代码:
if (condition) {
} else {
}
都被人改成了:
if (condition) {
}
return y;
请问这里省略了一个“else”和两个花括号,会带来什么好处或者坏处?
(提示,改过之后的代码不如原来的好。为什么?)
3. 根据本文对于 ++ 操作的看法,再参考传统的图灵机的设计,你是否发现图灵机的设计存在类似的问题?你如何改造图灵机,使得它不再存在这种问题?
(提示,注意图灵机的“读写头”。)
4. 参考这个《Go 语言入门指南》,看看你是否能从中发现由于“片面追求短小”而产生的,别的语言里都没有的设计错误?