C++编程规则

命名

驼峰法

驼峰法应适用于变量的命名。其形式主要是第一个单词的首字母小写，其余单词的首字母大写。例如aSimpleTest

普通命名

这种方法适用于类、函数、枚举的名称。其要点是所有单词首字母大写。例如SimpleDelete

全大写命名

这种方法适用于宏。所有字母都应该大写。

私有成员变量

这类变量应该采用驼峰法后面加下划线的格式进行命名。比如:aSimpleMember_

其他规则

（1）永远不要使用“晦涩的名称”，即以下划线开始或者包含双下划线的名称；

（2）表示宏的时候不要考虑使用常见的词或者缩略语作为宏的名称

组织和策略问题

规则1 高度重视代码中的警告

首先，需要使用编译器的最高警告级别，以此来发现很多潜在性问题。这些潜在性问题可能在当下没有体现出来，但其极可能在将来引发严重的错误（例如野指针，或者在某次编译器更新后程序出现了错误的行为）。一份高质量的代码在边缘时不应有任何警告。

例外情况

有些时候，编译器发出了某些没有意义的警告，在这种罕见的情况下，应该在局部禁用这种警告，并且注释为什么要禁用这种警告。如果在这种情况下忙着修改代码来解决警告，可能会事半功倍或者徒劳无功。因此，局部禁用该警告是最佳的选择。

规则2 使用自动化构建系统

这样做可以减小浪费在构建时的时间。一键化的构建系统可以极大的提升我们的效率

规则3 使用版本控制系统

使用任意一种版本控制系统来管理你的代码，并且不要长时间让一个文件登出，建议提高提交的频次，并且保证提交后的代码不会影响构建成功。

规则4 做代码审查(code review)

这样做有利于提高代码质量。对于团队来说，代码审查还可以让团队中的人相互学习对方的代码，并获得进步。同时也可以减少问题的发生。

这种审查千万不能形式主义。

设计风格

规则5 一个实体只有一个职责

一次解决一个问题，也就是给一个实体(类、函数等)一个定义良好的职责。这个职责不能过于发散，这样会增加他们的使用难度。例如，alarm函数就不应该去把与其没有多少关系的任务完成了。

具有多个不同职责的实体通常都是难于设计和实现的，同时应该用较小的低层抽象构建更高层次的抽象。要避免将几个低层抽象集合成一个较大的低层次抽象聚合体。用几个简单的行为来实现一个复杂的行为，比反其道而行之更加容易。

规则6 正确、简单、清晰第一

规则7 编程中应知道何时和如何考虑可伸缩性

要小心数据的爆炸性增长，考虑算法的时间复杂度和空间复杂度，但是要密切关注渐近复杂性。

规则8 不要进行不成熟的优化

规则9 不要进行不成熟的劣化

规则10 尽量减少全局和共享的数据

共享数据很容易导致各种个样的冲突，同时不利于代码之间的解耦合。

规则11 隐藏信息

不要公开提供抽象的实体的内部信息

规则12 懂得何时和如何进行并发性编程

在并发编程中要注意线程安全。在适当的地方加锁， 不要滥用锁。

规则13 确保资源为对象所拥有。使用显式的RAII和智能指针

C++的“资源获取即初始化”（Resource Acquisition Is Initialization，RAII）惯用法是正确处理资源的利器。合理的使用和编写构造函数和析构函数。