《代码整洁之道》观后感

　　这两天粗读了《代码整洁之道》——实际上真正只读了前面七章，后面的章节由于道行太浅，读不进去，发现与作者的很多观点不谋而合，读书时有点畅快的感觉，所以将映像深刻的几点记录一下。

命名

　　作者主张整洁代码中的命名应当清晰表达代码意图，不忌讳命名的长度，并且命名要比较容易发音，这样方便程序员们之间的沟通。带有前缀的命名被作者认为是不必要的，因为这是旧时代为方便代码阅读产生的，而现在强大的IDE对代码阅读非常友好。话说回来，我现在写的代码也有命名前缀的习惯，全局变量前加'g_'，静态变量前加's_'，指针前加'p_'，整体看上去确实挺烦的。

注释

　　作者主张代码中不应该出现太多无聊的注释，尤其是类似那种每个函数都必须写一个规则的注释头的做法。因为代码在不断修改，注释却很少有人同步修改，久而久之，注释就跟代码对不上了。况且在命名合理的前提下，函数名、变量名本身就展现了自己的用途，这一点深合我意，因为我一直暗自吹嘘，本人写的代码不需要注释也能看懂。

　　不过也不能完全抛弃注释，在一些重要的地方或者需要注意的地方加个注释是合理而且有用的。另外对外接口最好也认真写下注释，因为遇到过有人向我抱怨不知道某些个函数怎么传参数，怎么判断返回值。

　　比较讨厌的一种注释是把代码注释掉，并且保留下来。在工作中也经常遇到这种愚蠢的代码，不知道只是暂时不用还是完全不用，后面维护的人也不敢轻易删除，久而久之代码就乌烟瘴气。现在都用SVN或者GIT管理代码，对于不用的代码直接删除，服务器可以一直记录代码更改记录，不必担心某些代码后续有用找不到的情况。

函数

　　函数个体应该足够小，注重代码复用，相关联地函数应该放在一起，甚至包括使用到的变量，这样眼珠子甚至不用上下转动就可以尽览一个小模块的代码。关于返回值的处理，我有事也在思考，如果把所有的返回值都做处理，那代码何其复杂？！然而如果哪怕只剩下一行代码没有处理返回值，那么其它的努力有何意义？！作者让我坚定了之前一个想法：在一些关键、基础的函数内部，用异常替代返回错误值。例如，当创建一个信号量申请内存失败时，与其返回失败，不如直接进异常。因为此时系统赖以生存的内存资源都耗尽，再运行下去只会出更多的问题。

 

　　作者给我的感受是，以实用为宗旨，对陈腐套路杀伐果断。作者思想比较敏捷，他认为代码不可能一开始就按照设计规则就能写出来，应该先粗后细，不断改良。这也符合一般人编码的过程，而不像某些流派，要求先有详细设计，再实现代码。作者似乎也不完全赞同测试驱动开发的理论，不同意在写代码之前就完成单元测试的设计，但是他非常重视测试，好几章都讲到测试，没怎么做过测试的我，自惭形秽。

 

　　另外，我自己在工作中也有一些想法，好像在书中没有看到，记录一下。

编译零警告

　　我比较喜欢编译后没有警告的工程，尽管这不是代码上看到的。有的公司的工程，代码量不大，编译一下有上千个警告，显然经过很长时间才“发展”起来的。前面的人如果不处理好，后面的人看到这么多，不容易察觉自己模块的警告，也不处理，所以越来越随意。我想这也是代码不整洁的表现，并且有些警告在某些IDE里面可能是一些错误。

 

语言单一化

　　通常情况下，程序员做一个项目只用一种编程语言就可以了。可是有些程序员天赋异禀，为了达到某个他认为很酷的目的，引入另外一种语言。那么事情就变得复杂了，程序员们需要额外安装另一种语言的依赖软件，而且如果编译脚本没有实现一键编译的话，编译步骤都会被分解成若干部，另外还需要写一份文档，说明为何这么做。后续维护的程序员很有可能不懂这一门语言，也可能他会忘记这么多步骤，久而久之，这部分代码就成了累赘。