第二部分：设计风格

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

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

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

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

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

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

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

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