<<代码整洁之道 >>读书记录，包括：
第二章：有意义的命名
第三章：函数
第四章：注释

2.2名副其实
使用的命令能正确明白说明发生了什么。
2.3避免误导
如：accountList，只有真的是List类型，才这么命名
2.4做有意义的区分
如没意义的命名，Product，ProductInfo, ProductData,无法区分意义
2.5 使用读的出来的名称
命名不使用自造词，使用恰当的英语词
2.6 使用可搜索的名称
找WORK_DAYS_PER_WEEK很容易，但是找5很难找
2.7 避免使用编码
2.7.1 匈牙利命名法：现在不适用
如：PhoneNumber phoneString，类型改变时，名称并不会改变，对于用户会难以理解
2.7.2 成员前缀
消除对于成员前缀的需要
2.8 避免思维映射
明确是王道，应该避免把读者在脑中把你的名称翻译为他们熟知的名称。
2.9 类名
类名应该是名词或者名词短语，如：Customer，WikiPage，Account
避免使用Manager、Processor这样的类名
2.10 方法名
方法名应当是动词或动词短语，如postPayment，deletePage。
属性访问器与断言应该根据其值命名，并以Javabean标准加上get、set、is前缀
重载构造器
2.11 别扮可爱
2.12 每个概念对应一个词
2.13 别用双关语
2.14 使用解决方案领域的名字
2.15 使用源自所涉领域的名字
2.16 添加有意义的语境
如：firstName提供语境 addFirstName
2.17不要添加没用的语境

第三章：函数

3.1 短小
3.2只做一件事
3.3 每个函数一个抽象层级
3.4 switch语句
适时使用多态
3.5 使用描述性的语句
命名方式保持一致
如：includeTeardownPages
3.6 函数参数
参数越少越好
3.6.1 一元参数的普遍形式
3.6.2 标识参数：true、false，不要使用
3.6.3 二元参数
3.6.4 三元参数
3.6.5参数对象，当参数过多时（两个或以上），考虑封装为类。
3.6.6 参数列表
引入数量可变的参数：void triad(String name, int count, Interger... args)
3.6.7 动词与关键字
给函数取个好名字，动词或名词对
如：assertExpectedEqualsActual(expected, actual)
3.7 无副作用
函数承诺只做一件事，可能会做其他被藏起来的事
3.8 分隔指令和询问
函数要么做什么事，要么回答做什么事，两者不要兼得
3.9 使用异常替代返回错误码
3.9.1 抽离Try/Catch代码块
3.9.2 错误处理就是一件事
如果try在某个关键字中出现，他就该是这个函数的第一个单词，而且catch/finally后不该有其他内容
3.9.3 Error.java依赖磁铁
使用异常来替换枚举错误码
3.10 别重复自己
重复两次的代码可以单独抽离出来
3.11 结构化编程
每个函数和代码块都应该有一个入口和一个出口。遵循这些规则，每个函数只该有一个return，小函数可以根据情况另说

第四章：注释

4.1 注释不能美化糟糕的代码
4.2 用代码来阐述
让代码代替注释说话
4.3 好注释
唯一好的注释是你想办法不去写的注释
4.3.1法律信息
这类不应是合同或法典。只要有可能，就指向标准许可和其他外部文档，而不是把所有的条款放到注释中
4.3.2 提供信息的注释
这类有时管用，但更好的是利用函数名称来提供信息。
4.3.3 对意图的解释
4.3.4 阐释
帮助解释不能修改的代码含义
4.3.5 警示
警告其他程序员会出现的后果
4.3.6 TODO注释
应该做，还没有做的事情
4.3.7 放大
放大某种不合理之物的重要性
4.3.8 JavaDoc
编写公共API，必须
4.4 坏注释
4.4.1 喃喃自语
保证注释被人能够看懂
4.4.2 多余的注释
4.4.3 误导性注释
4.4.4 循规式注解
每个函数都要注解，每个变量都要解释是愚蠢的
4.4.5 日志式注解，不用
4.4.6 废话式注解
4.4.7 可怕的废话，避免JavaDoc中的废话
4.4.8 能用函数和变量时就别用注释
4.4.9 位置标记，删除
4.4.10 括号后的注释
4.4.11 归属和署名
4.4.12 注释掉的代码
4.4.13 HTML注释，禁用
4.4.14 非本地信息
注释应该描述最近的代码信息
4.4.15 信息过多
不要在注释中添加无关的信息
4.4.16 不明显联系
代码和注释应该相互联系
4.4.17 函数头
短函数不需要描述，选个好名字比使用函数头注释有用的多
4.4.18 非公共代码中的javadoc