一本就差不多了

温故而知新，重新复习一些C++的知识，有一段时间，出现了非常多关于C++编程规范类型的书籍。这些类型的书籍，很大部分内容是相同的，个人比较喜欢看《C++编程规范》，100条，条款来自《Effective C++》、《More Effective C++》、《Effective STL》、《Exceptional C++》、《More Exceptional C++》等各类书籍。

 
多年以后重新开始看这本书，又有新的收获：

1、不要拘泥小节

前段时间进行项目开发，小组内的开发人员可以说都是很优秀的开发人员，大家在一起开发，我想总希望能有一个基本的编程规范，很犹豫对于编程规范定义到什么级别。对于缩进、行的长度、注释、大括号的形式大家都有自己习惯的形式，对于这些编写的规范，说实话真的没有太大的必要。不管哪一种形式，只要代码比较清晰，很快就能习惯，读取代码（Review）都比较容易。对于函数名和变量名则需要统一的命名方式，这是大家都比较容易达成共识的编程规范，不要花太多时间去规范一些没有必要的规则，否则阻力很大，效果很差。

 

2、在高警告级别进行编译

最近一些开发工作主要是类库的开发，API的设计，所以对于代码的质量要求很高，这就要求对于编译器的各种警告都非常注意，很多bug的引入就是warning开始，很常见的unsigned int和int的转换比较，unsinged int的--操作、浮点数的精度问题等。

 

3、代码审查上的投入

项目的开发很产品的开发，其中一个很大的区别就在于生命周期的长短，项目只要验收了就可以，不一定会有后续的项目，但是产品的开发，生命周期很长（当然，因为产品被淘汰另当别论），代码的质量就非常的重要，根据用户的反馈，产品模块的优化升级。如果代码质量差，优化升级会成为一个很痛苦的过程，在产品的开发过程中，要在代码审查中投入。

4、正确、简单和清晰第一

上周和同事进行XP编程，发现同事很喜欢直接用调用函数并将函数的返回值作为参数传递，个人喜欢上非常不喜欢这种优化，一是调试很多时候无法看到返回值（纯虚类的接口）。二代码的清晰被破坏，可读性变差。再则我觉得这种优化根本没有必要，都是基本类型的。

 
5、积极使用Const

在做API设计的时候，需要考虑API的各种使用情况，需要提供const和非const的版本。


6、考虑将虚拟函数申明为非公用的，将公用函数申明为非虚拟的

在API设计中，经常会采用多层设计，实现类的设计中引入了虚拟函数和公用函数，避免公用函数被重载。

 
7、广泛的使用断言记录内部假设和不变式

越底层，越要采用断言，避免不要的条件判断影响性能以及错误的引入。

 
8、正确的报告、处理和转换错误

API的设计，一定要有这些处理和Log，否则用户无法知道错误的原因，导致可用性非常的差。

 
9、显式定义构造函数、析构函数、拷贝构造函数和复制函数。

 
10、还有一点是关于继承实现中的前置条件和后置条件的定义要非常的清晰明确。

 
《C++编程规范》的很多条例也是根据OOD的五大原则进行设计的。

 

1、单一职责原则（SRP）

2、开放-封闭原则

3、Liskov替换原则

4、依赖倒置原则

5、接口隔离原则