《C++编程规范（英文版）》（英文名：《C++ Coding Standards – 101 Rules, Cuidelines, and Best Practices》）
Herb Sutter, Andrei Alexandrescu 著

第一部分：组织和政策问题

0. 不要为小问题焦虑（要知道哪些无需规范化）
统一最重要，而具体统一成什么细节并不是那么重要，比如缩进是多少，每行长度多少，命名方式如何，注释方式如何，括号方式如何，TAB还是空格等等。另外提到两条传统的规范认为无需遵守，一是匈牙利命名法，二是函数的单入单出。
个人意见：对于一个团队来说，最好还是需要需要就一些细节的东西进行统一，当然统一成什么格式关系不大，没有哪种格式一定比别的格式好。单入单出我是早就反对的，但匈牙利命名法得很习惯了。现在看到的许多软件开发的书籍里都提到说匈牙利命名法对面向对象的语言是不适合的，最近也是有些体会，但主要集中在类型的重复上（对类似乎还可以，但对于Generic Programming显然毫无意义），自己觉得作用域的说明似乎还是有些好处的。一个程序里阅读的时候直接能知道哪些是类的成员变量，哪些是局部变量或者函数的参数。不过也许按照写小函数的原则，一个小函数中这一点也能够看得很清楚，也许也会慢慢觉得没有必要。

1.使用最高的警告级别进行编译
2.使用一个自动构造系统
3.使用一个版本控制系统
这几点都在遵循，但自动构造系统并没有对公司所有产品都这么用。另外，以前很多习惯仍然没有到达“建立工具，让机器替代人来工作”的自觉程度，有时候还是为图省事就手工做了，然后一遍遍重复做。

4.在软件复查上投资
做得不好，所以重复一下书中的理由：
* 通过有益的同伴压力来增加代码质量
* 找到bug，不可移植的代码（如果适用），以及潜在的伸缩性问题。
* 通过想法的杂交促进更好的设计以及实现
* 带领新的团队成员和新手加快速度
* 在团队内部培养共同的价值观和一种社区感觉
* 增强精英意识，自信，积极性以及职业自豪感。