Code complete 2th,代码大全第二版的中文书已经出来了


公司很早就买了这本书的英文版,硬皮的,非常厚实稳重的手感,无论如何不能便宜到100块人民币以内的样子。可惜感觉看上去有点吃力(是我水平不够啊),也就没有继续读下去,准备拿中文版看。不过我还是先等等,最近这些译者的态度和水平非常不咋地,比如我购买的《Joel on software》祖尔谈软件的中文版本,实在不容易读,那可都是中文阿。

CC2e:《代码大全(第2版)》集萃(陈硕)

CC2e:《代码大全(第2版)》集萃

《代码大全(第 2 版)》是一本写得很有意思的书,既有生动的比喻,偶尔也有夸张的表达,另外作者还时不时开开玩笑,读起来一点也不枯燥。以下是从中摘录的一些有趣的话。这个版本略有删节,等书出版之后,我会扩充这里的内容。

* 首先为人编写程序,其次才是为机器。

* 傻子都会写让计算机理解的代码;而优秀程序员写的是人能看懂的代码。(Martin Fowler)

* 好习惯很重要,因为程序员做的大部分事情都是无意识完成的。

* goto的标号应完全大写并对齐行首,还应包含编程者的名字、家庭电话号码和信用卡号。(Abdul Nizar)

* 编码时要把维护你程序的人想象成知道你住址的有严重暴力倾向的精神病人。(佚名)

* 有两种设计软件的方式:一种方法是让设计非常简单,看上去明显没有缺陷;另一种方法是让设计非常复杂,看上去没有明显的缺陷。(C. A. R Hoare)
* 忽略编译器所提示的程序错误太过草率,关掉编译器的警告功能则无异于掩耳盗铃。关掉编译器的警告功能仅仅意味着你看不到错误,并不表示这些错误就此消失,正如同小孩闭上眼睛并不能让面前的父母从此消失一样。

* 想通过更多测试来改善软件的质量,就跟妄想通过更频繁的称体重来减肥一样。(编按:作者并不是说测试无用,而是说不能仅仅依靠测试。)

* 心理取向对调试有什么影响?首先,它证明了养成良好的编程习惯的重要性。规范的格式、恰当的注释、良好的变量和子程序命名方式,以及其他编程风格要素都有助于构建编程的良好基础。在这样的基础之上,可能发生的错误将因为与众不同而变得格外引人注目。

* 交互式调试器极好地代表了那些程序员们并不需要的调试器——它鼓励程序员采用随机试验查找错误的方法,而不是对程序进行系统的分析。同时,这样的工具也给了那些几乎没有资格从事细致的程序设计的人滥竽充数的机会。(Harlan Mills)

* 聪明不像是个人性格的一个方面,也确实不是。碰巧的是,高智商与优秀程序员之间并无太密切的联系。

* 懒惰这种品性能促使你努力减少整体花销;使你编写节省劳力的程序,别人也会觉得这些程序有用;使你编些说明,免得人们老是问你。(Larry Wall)

* 你可能某天从上午8点工作到下午2点,就感到累得不行了。但你还是坚持下来,又从下午2点拼命干到5点。之后的一周时间,你却在修改这三小时里写出来的东西。

* 有效编程中最重要的工作是思考,而人思考时通常不会看上去很忙。如果和我共事的程序员总是忙个不停,我会认为他并非优秀的程序员,因为他没用最有价值的工具——自己的脑袋。

* “我们需要有五年以上C语言编程经验的程序员”就是愚蠢的说法。如果程序员过了前一两年还没有学好C语言,那么再加三年也没什么意义。

* 调试代码的难度是首次编写这些代码的两倍。因此,如果你在编写代码的时候就已经发挥了全部聪明才智,那么按照常理,你将无法凭借自己的智慧去调试这些代码。(Brian Kernighan)

* “这个循环好像有问题。可能是一个off-by-one错误。让我先来写一个-1试试。哦,这样不行。那么我就写个+1试试。啊哈,看来程序正常工作了。我可以宣布问题搞定了。”——随机地修改代码,直到你的代码看起来能工作,这就是所谓的“voodoo programming(巫毒编程)”。

* 每个团队里都也许有这样一个程序员,他总会遇到无穷的问题:不听话的机器,奇怪的编译器错误,月圆时才会出现的编程语言的隐藏缺陷,失效的数据,忘记做的重要改动,一个不能正常保存程序的疯狂的编辑器——你怎么描述这种行为好呢。这就是“迷信式编程(programming by superstition)”。

最后谈一点,数学对编程很重要吗?纵观《代码大全》,作者谈了影响软件质量的方方面面,却*没有*说过程序员的数学功底是一个重要的影响因素。对程序员而言,掌握数学知识也不是必备技能。就我看来,数学不是决定性因素,甚至算不上重要因素。我没有听说过哪个软件项目因为开发人员数学功底不好而失败,或者因为在数学方面的不足使得质量低下、bug 丛生。

首先,数学是一门很大的学科,有非常多的分支。如果认为它很重要,必需列出到底其中哪些知识会影响软件开发,这样才有指导意义。我个人感觉,项目开发直接用到的数学知识很少。而且如果真的要用到,涉及的代码比例也不会很大,那么整个项目组里有一两个人(不一定是程序员)精通就行了(借助封装+抽象,让它是个黑盒子)。

与其强调抽象的“数学知识”,不如强调具体的“领域知识”。有些领域知识会涉及一些数学,比如我熟悉的有数值计算、电路分析、图像处理、信号处理等。不过这些数学知识都是针对这个领域的,而且经过领域知识的封装。有些领域几乎不涉及数学(前提是你不要把所有与思考相关的都归入“数学”),比如数字电路设计、体育比赛记分、以及很多常见的软件项目(考勤、系统工具、网站)。这些领域也都有各自的领域知识,不掌握这些知识肯定没法写软件,不过跟数学好像没什么关系。

总而言之,相比起程序员的其他职业素养(求知欲、诚实、交流能力、懒惰、良好的习惯等等),“数学知识”实在排不上号。

ps. 我是这本书的 4 名译者之一,我不可能向各位提供电子版。


《 “Code complete 2th,代码大全第二版的中文书已经出来了” 》 有 2 条评论

发表回复

您的电子邮箱地址不会被公开。 必填项已用 * 标注