第一章
1、我们永远无法抛弃必要的精确性—所以代码永存。
2、糟糕的代码会毁掉一个公司
3、勒布朗（LeBlanc）法则：稍后等于永不。
4、混乱的代价：对代码的每次修改都影响到其他两三处代码。修改无小事。每次添加或修改代码，都得对那堆扭纹柴了然于心，这样才能往上扔更多的扭纹柴。这团乱麻越来越大，再也无法理清，最后束手无策。
5、制造混乱无助于加快进度，真正能加快进度的方法就是写整洁的代码
6、写整洁代码就像是绘画，能分辨整洁代码和肮脏代码，不代表着能写整洁代码。
7、代码逻辑应当直截了当，叫缺陷难以隐藏；尽量减少依赖关系，使之便于维护；依据某种分层战略完善错误处理代码；性能调至最优，省得引诱别人做没规矩的优化，搞出一堆混乱来--->逻辑直截了当，减少依赖，完善错误处理，性能调至最优
8、破窗理论
9、完善错误处理代码。往深处说就是在细节上花心思。
10、整洁的代码力求集中。每个函数、每个类和每个模块都全神贯注于一事，完全不受四周细节的干扰和污染。
11、减少重复代码，提高表达力，提早构建简单抽象。
12、读与写花费时间的比例超过 10:1。所以使之易读实际也使之易写。
第二章
1、名副其实。变量、函数或类的名称应该已经答复了所有的大问题。它该告诉你，它为什么会存在，它做什么事，应该怎么用。如果名称需要注释来补充，那就不算是名副其实。
2、错误：
```
int d; // 消逝的时间，以日计
```
正确：
```
int elapsedTimeInDays;
int daysSinceCreation;
int daysSinceModification;
int fileAgeInDays;
```
错误:
```
public List<int[]> getThem() {
List<int[]> list1 = new ArrayList<int[]>();
for (int[] x : theList)
if (x[0] == 4)
list1.add(x);
return list1;
}
```
问题不在于简洁度而在于模糊度，不能表明要执行的功能。
改进：
```
public List<int[]> getFlaggedCells() {
List<int[]> flaggedCells = new ArrayList<int[]>();
for (int[] cell : gameBoard)
if (cell[STATUS_VALUE] == FLAGGED)
flaggedCells.add(cell);
return flaggedCells;
}
```
改进2：
```
public List<Cell> getFlaggedCells() {
List<Cell> flaggedCells = new ArrayList<Cell>();
for (Cell cell : gameBoard)
if (cell.isFlagged())
flaggedCells.add(cell);
return flaggedCells;
}
```
3、避免误导
程序员必须避免留下掩藏代码本意的错误线索。
- 应当避免使用与本意相悖的词。
- 别用 accountList来指称一组账号，除非它真的是 List 类型。
- 提防使用不同之处较小的名称。
- 拼写前后一致
4、做有意义的区分
如果程序员只是为满足编译器或解释器的需要而写代码，就会制造麻烦。
以数字系列命名（a1、a2，„„aN）是依义命名的对立面。这样的名称纯属误导—完全没有提供正确信息；没有提供导向作者意图的线索。
废话是另一种没意义的区分。假设你有一个 Product 类。如果还有一个 ProductInfo 或 ProductData 类，那它们的名称虽然不同，意思却无区别。
注意，只要体现出有意义的区分，使用 a 和 the 这样的前缀就没错。
5、使用读得出来的名称
6、使用可搜索的名称
单字母名称和数字常量有个问题，就是很难在一大篇文字中找出来。
单字母名称仅用于短方法中的本地变量。名称长短应与其作用域大小相对应。
7、避免使用编码
不必用 m_前缀来标明成员变量。应当把类和函数做得足够小，消除对成员前缀的需要。
ShapeFactoryImp，甚至是丑
陋的 CShapeFactory，都比对接口名称编码来得好。
8、避免思维映射
不应当让读者在脑中把你的名称翻译为他们熟知的名称。
专业程序员了解，明确是王道。专业程序员善用其能，编写其他人能理解的代码。
9、类名
类名和对象名应该是名词或名词短语，类名不应该是动词。
10、方法名
方法名应当是动词或动词短语。属性访问器、修改器和断言应该根据其值命名，并加上 get、set 和 is 前缀。
11、别扮可爱
宁可明确，毋为好玩。
12、每个概念对应一个词
给每个抽象概念选一个词，并且一以贯之。函数名称应当独一无二，而且要保持一致，这样你才能不借助多余的浏览就找到正确的方法。
13、别用双关语
避免将同一单词用于不同目的。同一术语用于不同概念，基本上就是双关语了。
在多个类中都有add方法，该方法通过增加或连接两个现存值来获得新值。假设要写个新类，该类中有一个方法，把单个参数放到群集（collection）中。该把这个方法叫做 add吗？这样做貌似和其他 add 方法保持了一致，但实际上语义却不同，应该用 insert 或 append 之类词来命名才对。把该方法命名为 add，就是双关语了。
14、使用解决方案领域名称
给这些事取个技术性的名称，通常是最靠谱的做法
15、使用源自所涉问题领域的名称
++如果不能用程序员熟悉的术语来给手头的工作命名++，就采用从所涉问题领域而来的名称吧
16、添加有意义的语境
很少有名称是能自我说明的—多数都不能。反之，你需要用有良好命名的类、函数或名称空间来放置名称，给读者提供语境。
如firstName、lastName、我们可以添加前缀addrFirstName、addrLastName来添加语境。
17、不要添加没用的语境
只要短名称足够清楚，就要比长名称好。别给名称添加不必要的语境。