打印本文 
关闭窗口 第0条：不要拘泥于细节（了解哪些东西不应该标准化）
·缩进：不必规定如何缩进，每个人遵从一个自己喜欢的规则即可。
·行长：今天已经没有太大的必要限制80个字符了，当然，越有利于阅读越好。
·命名：不要太严苛，除了宏应该全部大写外，别的只要遵从某种大家接受的风格即可。常见的风格有2种，一种是连字符连接全部小写的单词，另一种是单词首字母大写。如果需要使用各种第三方库，基本上很难保持一种风格。在一定的范围内保持一致，目标是使得阅读更容易即可。
·注释：不要规定注释的格式。不过，使用doxygen语法的注释是个好主意，我一直用doxygen产生文档。
·匈牙利记法：很高兴，我为自己厌恶的东西找到了支持我的同盟军。在C++语言中借助一点小伎俩来表达类型是无益的，C++压根就不需要这些，它只会带来混乱。
·单入口单出口：在支持异常和确定性析构的C++世界，这是多余的。
在这里，旗帜鲜明地反对了两样东西：匈牙利记法和单入单出原则。
第1条：在高警告级别干净利落地编译
把编译器的警告级别开到最大，并且能够悄无声息地生成结果。对于那种视警告如无物的人，关门！放狗！也不要轻易的在源代码中关闭编译器警告。
·对于第三方库，在包含文件周围加以屏蔽即可。
·未使用参数：不提供该参数名称即可。
·未使用的变量：插入一个该变量的表达式即可。这算是一个惯用法了，会比较多的用到。
·变量未初始化：初始化。需要通过一个过程来初始化的例外，即形如：obj; init_obj(obj);
·某些分支没有return返回值。在这些分支上加入断言：assert(false);再接一个return返回值。
·有、无符号不匹配。如果无法避免，预先写好强制转换。个人认为，尽量避免无符号数，即使是处理理论上就没有符号的数据，有符号数适应性更好。几乎没有必要使用无符号数---除了某些位操作。
第2条：使用自动构建系统
这个就是DailyBuild嘛！对一个团队项目而言，DailyBuild就是心跳，它应该可以通过一个按钮或是一条命令就能构建出整个系统。您的心跳正常吗？这里的关键是：只要一个操作就能完成所有工作。
第3条：使用版本控制系统
还有那个团队没有使用VCs？如果没有，“盲人骑瞎马，夜半临深池”，真是极好的写照。
第4条：在代码审查上投入
很多团队其实是没有有效的代码审查的。亮出自己的代码，阅读别人的代码，这也是熟悉整个项目的好方法。把代码投影在墙上，几个人坐下来一起评论也是有效的方法。
第5条：一个实体应该只有一个紧凑的职责
单一职责原则。这个原则并不那么容易执行，即使是STL这样的程序库，也一样会犯违反该原则的错误。在这里，举了两个违反这一原则的著名实现：realloc和stl 中的basic_string。不过，对于basic_string，我想比起MFC中的CString还是好了不少。在《Exceptional C++ style》中，对basic_string作了剖析，并且得出一个普遍的原则：尽量将函数实现为独立的函数而不是成员函数。
尝试用一句话来说明一个模块的功能，既不多，也不少。如果无法用这样的一句话加以概括，那么重新考虑规划该模块的职责。
打印本文 关闭窗口