《凌波微步软件开发警戒案例集》随笔

书中对于代码规范有非常详细的讲解和举例，是非常有价值的参考资料。编译技术似乎不仅仅是一种沟通和交流的机制。如果从编译技术的发展和演化上去推究，编译技术倒更像是贯穿不同的软件文化、联结不同的技术发展阶段的一座桥梁。许多计算机软件发展史上值得人们注意的关键事件，许多煊赫一时、引得全世界程序员们趋之若鹜的技术体系，都与编译技术本身有着直接或者间接的关联。

风格篇：

程序中“注释”的最重要的功效在于传承。传承一般有两种情况。第一，写代码的人写完这段代码之后会去写下一段代码、下下一段代码，直写到东西莫辨、朝午不明，也许过了一年半载以后，客户提出新的改动需求时，他才会回过头来看原来的代码。为了在未来的某个时候更快地接上当时编码的思路，更好地理解已尘封数月的程序，当然要未雨绸缪，事先就写好注释，否则不被老板痛骂才怪。第二，没有人愿意永远维护自己写过的代码，也没有老板可以保证手下的编程高手不会另择高枝，所以心地善良的程序员们总会写好注释(当然还有设计文档)以方便他人，自己也可以顺便找些“前人栽树，后人乘凉”的幸福感觉来。因此，就“传承”而言，注释至少应该具备以下这些特点:
第一，注释应当浅显、明白。给程序加上些诘屈整牙、形同天书的注释还不如不加的好。举个例子，我见过一个程序员把注释当作了他的私人日记本，在代码的注释中用只有他自己才懂得的特殊标记，把他在开发过程中的感想、计划、设计思路都记下来。

注释不是越多越好。
不要亦步亦趋。
多站在后来者的角度想一想。

风格不要妨碍沟通。
混合多种风格等于没有风格。
没有个性特点的代码未必就是好代码。

任何语法规则都有被滥用的可能。风格的优劣取决于选择的正确与否。
选择的前提是:由此产生的代码更加简洁、清晰、高效、易维护。

只有在必要的情况下，才使用特殊的编译选项。
一定要注意你自己对编译选项的选择是否会给项目组的其他成员，或今后的代码维护人员带来麻烦。

编码篇：

今天的面向对象理论至少还面临着以下置疑:
1.面向对象方法的培训周期明显长于结构化方法，教科书却还在大肆宣扬面向对象的概念更符合人类的思维习惯，更容易掌握。
2.“面向对象的软件工程”显然与传统的软件工程理论有相当大的差异，即使是 Rational 公司的那几个开山鼻祖也还在不断地对他们的理论修修补补。
3.UML只是面向对象设计的开始。目前的UML还有些难以理解，对复杂应用的表达能力也还比较有限。
4．适应于面向对象机制的测试理论和自动测试工具都亟待发展，距离成熟易用的阶段好像还比较遥远。
5．多态性、多重继承、虚基类、私有成员、内嵌类……这些都是面向对象技术对测试人员的信心和能力的挑战。要知道，一段只有10行的新代码很可能会让 100 000行已经测试过的代码暴露出新的错误。
6.事件-消息处理机制至今没有一种通行的标准。
7.“异常处理”技术很容易被不那么有经验的程序员们变成一种新的“意大利面条”制造器，因为谁也没办法很快弄清楚一个拥有15种异常对象和7层异常嵌套的代码，其实际执行顺序到底是怎样的。
8．基于面向对象理论的通讯和分布式应用模型还处在变动之中。CORBA和 DCOM的竞争还没有结束，SOAP和Web Services也许只适用于某些应用，传统的Named Pipe，Sockets 和 RPC还在大行其道。
9.…….
我们知道，代码中随意出现的goto会使程序流程混乱不堪，但多重循环中的goto 显然可以更清楚、更快速地跳到所有循环之外。典型的多重循环的例子经常出现在3D建模、图像处理、统计学等喜欢使用多维数组的场合。