C++编程规范（一）组织和策略上的问题

0. 不要拘泥于小节（Don't sweat the small stuff, 知道什么不要标准化）

 

这一章最有价值的条款：0.

 

在编码规范方面，不应该制定过于死板的准则。一个专业的程序员应该能够很容易阅读和编写与自己习惯的编码风格有所不同的代码。我们可以要求在一个文件或一个工程中采用一致的代码格式化，但是不需要在公司范围内或多个工程中也要求一致的编码方式。重要的不是设定编程规范，而是和已经在使用的规范保持一致。
1.不要规定缩进多少，而应该规定用缩进来表示代码结构
2.不要强制规定一行代码的长度，而是要保证代码长度便于阅读。
3.不要在命名方面规定过多，而是采用一致的命名规范
4.不要规定注释风格，而应该编写有用的注释。

例3.匈牙利记法：将类型信息和变量名结合在一起的记法，是mixed utility in type-unsafe languages (notably C),在面向对象语言中是可以存在，但是没有益处，对于泛型编程则是不可行。
例4.单入口单出口(SESE, single entry, single exit)，历史上有些编程规范要求每个函数有一个出口，即只有一个return语句。但是对于支持异常和析构的语言，函数可能存在多个隐晦的出口。因此，遵循条款5那样的标准，提倡更简短的函数，更易于理解和不易出错。

1.在高警告级别干净的编译
这里的干净指的是warning-free，不能无视警告，而应该通过修改代码来消除警告而不是降低警告级别。

注：其实很多时候是没有做到warning-free的，因为有一些警告并不是由于代码本身的问题，因此通常对于这些警告并没有进行处理。本人在开发过程中也常常忽视一些无关痛痒的警告。

 

2.使用一个自动的build系统
使用一个完全自动的build系统在没有用户干涉的情况下build一个系统。

 

注：这点我们平时倒是还有做到。

 

3.使用版本控制系统
别使文件check out过长时间。在更新的单元测试通过后就check in。确保check in的代码不会影响build。

 

4.在代码review上投入(Invest in code reviews)
通过来自同伴的良性压力提高代码质量
找出错误，不可移植的代码和潜在的扩展问题
通过思想交流获得更好的设计和实现
快速培养新同事和初入门者
在团队中形成共同的价值观和集体主义
增强整体实力，提升自信心，动力和职业荣誉感。