第1章 整洁代码
重视测试
不要重复代码
提高表达力（保持逻辑简单直接）
构建简单抽象（小规模抽象）
只做好一件事
减少依赖关系
“整洁的代码总是看起来像是某位特别在意它的人写的。几乎没有改进的余地。代码作者什么都想到了，如果你企图改进它，总会回到原点，赞叹某人留给你的代码 —— 全心投入的某人留下的代码。”
第2章 有意义的命名
1.名副其实
避免以下不明确的命名：
int d;
std::list<int> theList;
2.避免误导
要避免将循环计数器命名为 l 或 o，因为它们分别容易和数字 1 和 0 混淆。
要避免用 accountList 来指称一组账号。list 一词对程序员有特殊意义。如果容纳账号的容器并非真是个 list，就会引起错误的判断。所以，用 accountGroup 或直接用 accounts 都会好一些。
3.做有意义的区分
废话就是一种没意义的区分。假设你有一个 Product 类。如果还有一个 ProductInfo 或 ProductData 类，那它们的名称虽然不同，意思却无区别。Info 和 Data 就像 a、an 和 the 一样是意义含混的废话。
4.避免使用编码
避免使用匈牙利标记法。
也不必用 m_ 前缀来标明成员变量。应当把类和函数设计得足够小，消除对成员前缀的需要。
5.类名
类名和对象名应该是名词或名词短语，如 Customer、WikiPage、Account 和 AddressParser。避免使用 Manager、Processor、Data 或 Info 这样的类名。
6.方法名
方法名应当是动词或动词短语，如 postPayment、deletePage 或 save。属性访问器、修改器和断言应该根据其值命名，并加上 get、set 和 is 前缀。
7.每个概念对应一个词
给每个抽象概念选一个词，并且一以贯之。假如在同一堆代码中有 controller，又有 manager，还有 driver，就会令人困惑。DeviceManager 和 ProtocolController 之间有何根本区别？为什么不全用 controllers 或 managers 呢？
8.别用双关语
即避免将同一单词用于不同目的或不同概念。
9.只要短名称足够清楚，就要比长名称好。
第3章 函数
1.短小
2.只做一件事
有时候一件事会有多个步骤，如果函数只是做了该函数名下同一抽象层上的步骤，则函数还是只做了一件事。编写函数毕竟是为了把大一些的概念（换言之，函数的名称）拆分为另一抽象层上的一系列步骤。
要判断函数是否不止做了一件事，还有一个方法，就是看是否能再拆出一个函数，该函数不仅只是单纯地诠释其实现。
3.参数对象
如果函数看来需要两个、三个或三个以上参数，就说明其中一些参数应该封装为类了。
4.无副作用
避免时序性耦合（即函数只能在特定时刻调用）。
避免使用输出参数。如果函数必须要修改某种状态，就修改所属对象的状态吧。
5.分隔查询和修改操作
6.使用异常替代返回错误码
7.消除重复代码
优雅的代码是不断打磨出来的。
每个系统都是使用某种领域特定语言搭建，而这种语言是程序员设计来描述那个系统的。函数是语言的动词，类是名词。编程艺术是且一直就是语言设计的艺术。
第5章 格式
若某个函数调用了另外一个，就应该把它们放到一起，而且调用者应该放在被调用者上面。
第6章 对象和数据结构
对象与数据结构之间的二分原理：
过程式代码（使用数据结构的代码）便于在不改动既有数据结构的前提下添加新函数。面向对象代码便于在不改动既有函数的前提下添加新类。反过来也说得通：过程式代码难以添加新数据结构，因为必须修改所有函数。面向对象代码难以添加新函数，因为必须修改所有类。
所以，对于面向对象较难的事，对于过程式代码却较容易，反之亦然！
在任何一个复杂系统中，都会有需要添加新数据类型而不是新函数的时候，这时，对象和面向对象就比较合适。另一方面，也会有想要添加新函数而不是数据类型的时候。在这种情况下，过程式代码和数据结构更合适。
第10章 类
单一权责原则：系统应该由许多短小的类而不是少量巨大的类组成。每个小类封装一个权责，只有一个修改的原因，并与少数其他类一起协同达成期望的系统行为。
内聚：类应该只有少量成员变量。类中的每个成员函数都应该操作一个或多个成员变量。内聚性高，意味着类中的方法和变量互相依赖、互相结合成一个逻辑整体。
保持内聚性就会得到许多短小的类。
开放-闭合原则：类应当对扩展开放，对修改封闭。
依赖倒置原则：类应当依赖于抽象而不是依赖于具体细节。即接口和实现需分离。
第11章 系统
第17章 味道与启发
“对象是过程的抽象。线程是调度的抽象。”
TOBECONTINUE