C++编程规范之组织和策略问题（读书笔记）

第0条　不要拘泥于小节

摘要

只规定需要规定的事情：不要强制施加个人喜好或者过时的做法。

讨论

有些问题只是个人喜好，并不影响程序的正确性或者可读性，所以这些问题不应该出现在编程规范中。任何专业程序员都可以很容易地阅读和编写与其习惯的格式略有不同的代码。

1．应该在每个源文件乃至每个项目中都使用一致的格式，因为同一段代码中要在几种编程风格（style）之间换来换去是很不舒服的。但是无需在多个项目或者整个公司范围内强制实施一致的格式。

2．不要强制行的具体长度，应该保证代码行的长度有利于阅读

3．不要在命名方面规定过多，应该规定的是使用一致的命名规范：只有两点是必需的：（1）永远不要使用“晦涩的名称”，即以下划线开始或者包含双下划线的名称；（2）总是使用形如ONLY_UPPERCASE_NAMES的全大写字母表示宏，不要考虑使用常见的词或者缩略语作为宏的名称（包括常见的模板参数，比如T和U；像“#define T anything”这样的代码是极容易混淆的）。此外，应该使用一致的、有意义的名称，遵循文件的或者模块的规范。（如果你无法决定自己的命名规范，可以尝试如下命名规则：类、函数和枚举的名称形如LikeThis，即单词首字母大写；变量名形如likeThis，即第一个单词首字母小写，第二个单词首字母大写；私有成员变量名形如likeThis_；宏名称形如LIKE_THIS。）

4．不要规定注释体例（除非需要使用工具从特定的体例中提取出文档），应该编写有用的注释：尽可能编写代码而不是写注释（比如，见第16条）。不要在注释中重复写代码语义，这样很容易产生不一致。应该编写的是解释方法和原理的说明性注释。

5．不要尝试强制实施陈旧的规则，即使它们曾经在一些比较陈旧的编程规范中出现过。

 

 

 

第1条　在高警告级别干净利落地进行编译

摘要

高度重视警告：使用编译器的最高警告级别。应该要求构建是干净利落的（没有警告）。理解所有的警告。通过修改代码而不是降低警告级别来排除警告。

例外情况

有时候，编译器可能会发出烦人的甚至虚假的警告（即纯属噪声的警告），但是又没有提供消除的方法，这时忙于修改代码解决这个警告可能是劳而无功或者事倍功半的。如果遇到了这种罕见的情形，作为团队决定，应该避免对纯粹无益的警告再做无用功：单独禁用这个警告，但是要尽可能在局部禁用，并且编写一个清晰的注释，说明为什么必须禁用。

 

第2条　使用自动构建系统

摘要

一次按键就解决问题：使用完全自动化（“单操作”）的构建系统，无需用户干预即可构建整个项目。

 

第3条　使用版本控制系统

摘要

好记性不如烂笔头（中国谚语）：请使用版本控制系统（version control system，CVS）。永远不要让文件长时间地登出。在新的单元测试通过之后，应该频繁登入。确保登入的代码不会影响构建成功。

 

第4条　在代码审查上投入

摘要

审查代码：更多的关注有助于提高质量。亮出自己的代码，阅读别人的代码。互相学习，彼此都会受益。