C++编程规范 组织和策略问题

第0条 不要拘泥于小节（又名：了解那些东西不应该标准化）
只规定需要规定的事情：不要强制施加个人喜好或者过时的做法。
详细：
1、应该使用缩进来体现代码的结构。建议每个缩进使用4个空格或者设置编辑器的制表符大小为4个空格，并且应该在每个文件中保持一致。
2、应该保证代码行的长度有利于阅读。建议每行不超过10个单词。
3、应该使用一致的、有意义的命名规范。必须永远不要使用“晦涩的名称”，必须不要使用常见的词或者缩略语作为宏的名称（包括如：T和U等），不应该使用匈牙利命名法。建议命名规范如下：
类、函数和枚举的名称形如：LikeThis；
局部变量、形参和结构成员变量的名称形如：likeThis；
类成员变量名形如：likeThis_；
宏名称形如：LIKE_THIS。
4、应该编写有用的注释。不应该编写重复代码语义的注释，应该编写的是解释方法和原理的说明性注释。
5、括号的位置应该在每个文件中保持一致，建议使用如下方式：

void PuttingEachBraceOnItsOwnLine()
{
    // ...
}

6、不建议单入口、单出口方式编码，而应该以简洁、紧凑、单一职责方式编码。

第1条 在高警告级别干净利落地进行编译
高度重视警告：使用编译器的最高警告级别。应该要求构建是干净利落的（没有警告）。理解所有的警告。通过修改代码而不是降低警告级别来排除警告。
详细：
1、排除警告的正确做法是：(1)把它弄清楚；然后，(2)改写代码以排除警告，并使代码阅读者和编译器都能更加清楚，代码是按编写者的意图执行的。
2、对于无法修改的第三方头文件引起的警告（可能是良性的），采用以下方式屏蔽：
自定义 format.h 文件：

// 本文件包装了 Boost 的 format.hpp。
// 应该总是包含此文件，而不要直接使用 format.hpp。
// Boost.Format 会产生一些已知无害的编译器警告。
// 在改正以后，我们将删除以下的编译指示，但此头文件仍然存在。
#pragma warning(push) // 仅禁用此头文件
#pragma warning(disable : 4819)
#include <boost/format.hpp>
#pragma warning(pop) // 恢复最初的警告级别

3、未使用的函数参数，首先确认是否需要保留以作日后扩展之用，如是可以采用注释掉变量名的方式处理。
4、定义了从未使用过的变量，首先检查是否是正确的，如是可以通过插入一个变量本身的求值表达式处理（这种求值不会影响运行时的速度）。
5、变量使用前可能未经初始化，则初始化变量。
6、遗漏了 return 语句，则检查并加上 return 语句。
7、有符号数/无符号数不匹配，则修改数据类型或者添加显式的类型转换。

第2条 使用自动构建系统
一次按键就解决问题：使用完全自动化（“单操作”）的构建系统，无需用户干预即可构建整个项目。
详细：
1、我们不应该将时间和精力浪费在机器可以干得更快更好的事情上。
2、两次连续增量构建中的第二次构建不应该编写任何输出文件；否则，可能会出现依赖循环（ 见 C22）。
3、可以考虑通过改变许多基本特性来参数化控制构建过程的参数；候选的特性包括目标架构，调试模式还是发布模式，以及范围（基本文件、所有文件、还是完整的安装文件）。
4、大型项目可能应该设置一个“构建管理员”，他的工作就是负责构建系统。

第3条 使用版本控制系统
好记性不如烂笔头（中国谚语）：请使用版本控制系统（version control system, VCS）。永远不要让文件长时间地登出。在新的单元测试通过之后，应该频繁登入。确保登入的代码不会影响构建成功。
详细：
1、问题并不在于你是否想从历史中寻找答案，而在于你到底何时需要。
2、不要破坏构建。版本控制系统中的代码必须总能构建成功。

第4条 在代码审查上投入
审查代码：更多得关注有助于提供质量。亮出自己的代码，阅读别人的代码。互相学习，彼此都会受益。
详细：
1、通过来自同伴的良性压力提高代码质量。
2、找出错误、不可移植的代码（如果适用）和潜在的扩展问题。
3、通过思想交流获得更好的设计和实现。
4、快速培养新同事和初入门者。
5、在团队中形成共同的价值观和集体主义。
6、增强整体实力，提升自信心、动力和职业荣誉感。
7、代码审查有助于提高软件的安全性、而且还是内部培训的一种极佳方法（而且没有成本）！
8、极限编程中的结对编程也是代码审查的一种方式， 详细可参考这里。

返回 目录

返回《C++ 编程规范及惯用法》