第二部分：设计风格

5. 给一个实体一个内聚的职责
倾向于从小一些的低层抽象构造高层抽象；避免将许多低层抽象集合成一个更大的低层抽象。从一些简单个体完成复杂行为要比相反的更容易。
两个声名狼藉的例子：realloc 和 basic_string

6. 正确性，简单性，和清晰性先行
这是第二部分最重要的一条，其实重要性不言自明

7. 知道何时和如何为可伸缩性编写代码
在一切可能情况下使用线性（或更好的）算法；在一切合理情况下避免使用比线性差的多项式复杂度的算法；在任何时候避免使用指数复杂度的算法。

8. 避免过早优化
9. 避免过早恶化（pessimize)
这两条应该一起说，因为常常有人搞混。这里作者将“过早优化”定义为以优化的名义将设计和编码搞得更加复杂，也因此更加不可读，实际上并没有被证明的性能需求，因而也明显地没有为你的程序增加被证明的价值。

让一个正确的程序快起来要比让一个快的程序正确要容易得多得多。

不要进行过早优化的两个理由：1. 我们程序员并不能能准确地评估代码中的瓶颈，因为现在的计算机计算模型十分复杂。因此，要优化必须通过准确地实际度量。2. 现在越来越多的瓶颈不在于CPU的限制，而是内存、网络、磁盘、Web Service。数据库等等的等待上，因此实际上要优化的是如何减少这种等待时间而不是程序运行的时间。

但是，这并不意味着不注意一些效率上的考虑，这就是第9项想说明的：避免过早地恶化。
这些考虑包括：传递引用而不是传递值；使用前置++和–运算符而不是后置运算符；使用构造函数中的赋值语句而不是初始化语句列表。减少对象不必须的临时拷贝，尤其在内循环中；使用现成的抽象、库和算法，例如STL。

因为这些手段的采用并未影响代码的可读性，因而也不会影响代码的复杂性，相反，有时候还降低了代码的复杂性。

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

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

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

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

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