代码简洁之道-总结

第 7 章 错误处理.... 95
2.12 每个概念对应一个词: 这两个对象是不同类型的，也分属不同的类。
2.13 别用双关语.:避免将同一单词用于不同目的,遵循“一词一义”
2.14 使用解决方案领域名称: 给这些事取个技术性的名称，通常是最靠谱的做法。如：JobQueue
2.15 使用源自所涉问题领域的名称
6.2 数据、对象的反对称性
添加新数据类型适用于对象和面向对象（多态）；添加新函数适用于过程式代码和数据结构
6.3 得墨忒耳律：对象隐藏数据，暴露操作。方法不应调用由任何函数返回的对象的方法
6.3.1 火车失事 91
6.3.2 混杂.............. 92
2.3 避免误导
(误导性名称真正可怕的例子，是用小写字母 l 和大写字母 O 作为变量名，尤其是在组合使用的时候。当然，问题在于它们看起来完全像是常量“壹”和“零”。 ）
2.4 做有意义的区分
（错误示范：getActiveAccount(); getActiveAccounts(); 正确示范：source 和 destination )
— 体现系统中的全部设计理念； （代码简洁、清楚）
— 包括尽量少的实体，比如类、方法、函数等。
如果对象功能太多，最好是切分为两个或多个对象。
如果方法功能太多，使用抽取手段（Extract Method）重构之，从而得到一个能较为清晰地说明自身功能的方法，以及另外数个说明如何实现这些功能的方法。
2.7.1 匈牙利语标记法、成员前缀、接口和实现
2.8 避免思维映射....... 22
2.9 类名:类名和对象名应该是名词或名词短语，类名不应当是动词。
2.10 方法名:方法名应当是动词或动词短语
2.11 别扮可爱 HolyHandGrenade：DeleteItem
5.2.3 垂直方向上的靠近.................. 74
5.2.4 垂直距离 75
5.2.5 垂直顺序 79
5.3 横向格式.. 79
5.3.1 水平方向上的区隔与 靠近............... 80
5.3.2 水平对齐 81
2.5 使用读得出来的名称
（ ！生成时间戳（generation timestamp） private Date genymdhms; private Date modymdhms; private Date generationTimestamp; private Date modificationTimestamp;
4.4.9 位置标记 ：尽量少用标记栏，只在特别有价值的时候用。
4.4.10 括号后面的注释...................... 62
4.4.11 归属与署名 源代码控制系统更善于记住这类信息，所以签名没有必要
4.4.12 注释掉的代码 作者建议是删掉
4.4.13 HTML 注释...................................... 64
5.3.3 缩进.............. 82
5.3.4 空范围....... 84
5.4 团队规则.. 84
5.5 鲍勃大叔的格式规则................................ 85
第 6 章 对象和数据结构.. 87
6.1 数据抽象 :隐藏实现关乎抽象，暴露抽象接口，以便用户无需了解数据的实现就能操作数据本体
3.9.2 错误处理就是一件事
3.9.3 Error.java 依赖磁铁
错误码枚举，当枚举修改时，所有这些其他的类都需要重新编译和部署，枚举造成了负面压力
使用异常替代错误码，新异常就可以从异常类派生出来，无需重新编译或重新部署。
3.10 别重复自己： 臃肿 其次一次修改多出修改，容易增加错误的可能性
2.6 使用可搜索的名称
（建议：采用能表达意图的名称，貌似拉长了函数代码，但要想想看，WORK_DAYS_PER_WEEK 要比数字 5 好找得多，而列表中也只剩下了体现作者意图的名称。
2.7 避免使用编码.
（避免把类型或作用域编进名称里面 。Fortran 语言要求首字母体现出类型，导致了编码的产生。BASIC 早期版本只允许使用一个字母再加上一位数字）
3.11 结构化编程.
3.12 如何写出这样的函数
3.13 小结
3.14 SetupTeardownIncluder 程序
3.15 文献
第 4 章 注释：注释的作用是解释未能自行解释的代码
4.1 注释不能美化糟糕的代码 ：带有少量注释的整洁而有表达力的代码要比带有大量注释的零碎而复杂的代码靠谱
如果不能用程序员熟悉的术语来给手头的工作命名，就采用从所涉问题领域而来的名称吧。至少，负责维护代码的程序员就能去请教领域专家了。
优秀的程序员和设计师，其工作之一就是分离解决方案领域和问题领域的概念。与所涉问题领域更为贴近的代码，应当采用源自问题领域的名称。
2.16 添加有意义的语境
4.4.5 日志式注释....................................... 59
4.4.6 废话注释 59
4.4.7 可怕的废话....................................... 61
4.4.8 能用函数或变量时就 别用注释. 62
如果你觉得写注释，就要花必要的时间确保写出最好的注释
4.4.2 多余的注释
读注释花的时间比读代码花的时间还要长的话。
4.4.3 误导性注释....................................... 58
4.4.4 循规式注释 ：并非每个函数都要有javadoc或每个变量都要有注释的规矩，这类注释会让代码变得散乱、迷惑不解
第 1 章 整洁代码…………………………………………………………………………………………………………………………………………………………. 1
贝克的简单代码规则
简单代码，依其重要顺序：
— 能通过所有测试； （前后台接口是通的、安全的、）
— 没有重复代码； (高内聚、低耦合)
3.6.3 二元函数
采用一些机制将其转换成一元函数
3.6.4 三元函数 39
3.6.5 参数对象 从参数创建对象，从而减少参数数量
3.6.6 参数列表 如果要向函数传入数量可变的参数，可以创建多个函数
3.6.7 动词与关键字 给函数取个好名字，能较好地解释函数的意图，以及参数的顺序和意图。
4.4.18 非公共代码中的 Javadoc ：JavaDoc对于公共API非常有用，不打算作公共用途的代码就不需要了
4.4.19 范例........... 66
4.5 文献................ 69
பைடு நூலகம்
第 5 章 格式.................. 71
3.5 使用描述性的名称.命名方式要保持一致。使用与模块名一脉相承的短语、名词和动词给函数命名。
3.6 函数参数.. 37
3.6.1 一元函数的普遍形式
转换：如果函数要对输入参数进行转换操作，转换结果就该体现为返回值
3.6.2 标识参数
解决方式：函数一分为二
3.1 短小. 函数的第一规则是要短小。第二条规则是还要更短小
3.2 只做一件事 函数应该做一件事。做好这件事。只做这一件事。
3.3 每个函数一个抽象层级 自顶向下读代码：向下规则
3.4 switch 语句
用于创建多态对象，隐藏在某个继承关系中， 抽象工厂
2.17 不要添加没用的语境
2.18 最后的话
奇怪的字符串和函数调用，混以双重嵌套、用标识来控制的 if 语句等，不一而足。
不过，只要做几个简单的方法抽离和重命名操作，加上一点点重构，就能在 9 行代码之内搞定（如代码清单 3-2 所示）
第 3 章 函数.................. 29
4.3.4 阐释：注释把某些晦涩难明的参数或返回值的意义 翻译为某种可读形式，
但是更好的方法是尽量让餐宿或返回值自身就足够清楚
4.3.5 警示：用于警告其他程序员会出现某种后果的注释
4.3.6 TODO 注释 ： 由于某些原因目前还没做的工作，但是要定期查看，删除不再需要的。
5.1 格式的目的 代码格式关乎沟通，对原始代码的修改，可读性和可维护性、扩展性的重要
5.2 垂直格式.. 72
5.2.1 向报纸学习....................................... 73
5.2.2 概念间垂直方向上的 区隔............... 73
4.4.14 非本地信息.................................... 64
4.4.15 信息过多：别在注释中添加有趣的历史性话题或者无关的细节描述
4.4.16 不明显的联系............................. 65
4.4.17 函数头 ：短函数不需要太多描述，取个好名字。
4.3.7 放大 ：注释可以用来放大某种看来不合理之物的重要性
4.3.8 公共 API中的 Javadoc............ 55
4.4 坏注释 ：糟糕的代码的支撑或借口
4.4.1 喃喃自语 55
如果只是因为你觉得应该或者因为过程需要就添加注释，那就是无谓之举。
3.7 无副作用
输出参数：应避免使用输出参数。如果函数必须要修改某种状态，就修改所属对象的状态吧