第1章 有意义的命名
- 废话是另一种没意义的区分
Info,Data就像a,an,the意义，是意义含混的废话
Product——ProductInfo——ProductData
Money——MoneyAccount
CustomInfo——Customer
AccountData——Account
TheMessage——Message
NameString
CustomerObject
第3章 函数
标识参数
标识参数丑陋不堪。reander(Boolean isSuite)应该改为reanderForSuite和reanderForSingleTest将二元函数转化为一元函数(应该尽量减少或者消灭参数)
二元函数一般比一元函数难以理解，可以通过下面的手法进行转化：
- 在类中将其中一个参数用字段表示，就不用传参了。
- 也可以将方法作为其中一个参数的方法，这种手法实际上是将函数（包括参数）的参数向上提到类中去。
将参数编码到函数名称
writeField(name)比write(name)好，因为前者告诉了我们name是一个field
assertExpectedEqualActual(expected, actual)比assertEqual好一些，这大大减轻了记忆参数顺序的负担。无副作用
函数应该只做一件事，但是还是可能会做其他预料之外的事情。参数应该只用作输入
appendFooter(s)会让人疑惑，这个函数是将s添加到某个什么东西后面？还是他把什么东西添加到s后面？s是输入参数还是输出参数？我们得稍微看下函数签名才能知道。
public void appendFooter(StringBuffer report)
面向对象中对输出参数的大部分需求以及小时了，因为 this也有输出参数的意味在内，最好是下面这样调用：
report.appendFooter
分隔指令与询问
只做一件事。函数要么做什么事，要么回答什么事，但二者不可兼得。不然会引起一些混乱，因为做什么事和回答什么事组合在一起，可能引起多种猜测。-
使用异常代替错误码
可以看到前者不会那么混乱，流程比较正常，跟平常的代码一样
错误处理就是一件事
void func(){
try{
XXX;
}catch{
YYY;
}
}
第4章 注释
注释很烂
只有在表达失败的时候才需要注释；程序员不能维护注释，只有代码能忠实地告诉你它做的事函数名或者变量名都可以起到注释的作用
第5章 格式
垂直距离
若某个函数调用了另外一个，就应该把它们放在一起，而且调用者应该尽可能放在被调用者上面。为什么调用者要放到上面？
我们指望最重要的概念先出来，细节在后面，查看前面的函数可能就知道了代码的意图。概念相关
概念相关的代码应该放到一起。水平方向上的区隔与靠近
我们使用空格字符将彼此紧密相关的事务连接到一起，也用空格字符把习惯性较弱的事物分隔开。
赋值语句的左边和右边用空格隔开
第6章 对象和数据结构
数据抽象
隐藏实现并非只是在变量之间放上一个函数层那么简单。隐藏实现关乎抽象！用户无需了解数据的实现就能操作数据本体。数据、对象的反对称性
这小节说的是过程式代码和面向对象代码的区别：
过程式代码就像集体主义，面向对象代码就像个人主义。
过程式代码函数书写的时候，操作全体数据（结构体），手把手，集体进行书写。如果添加多一个对象，那么所有函数都需要重新书写。
面向对象代码函数书写的时候，尽量让全体数据（对象）操作自己（对象.方法()），添加多一个数据（类），那么所有函数不需要重新书写，因为有多态。
过程式代码：方便添加函数，不方便添加数据。
面向对象代码：方便添加数据，不方便添加函数。德墨忒耳律
方法不应调用由任何函数返回的对象的方法，换而言之，只跟朋友谈话，不与陌生人（朋友的朋友）谈话。因为这样暴露了类的内部结构。书中举了这样的例子：final String outputDir = ctxt.getOptions().getScratchDir()...
我们取得这些内部结构，往往是为了用他们去做一些事情。类可以做的这些事情作为方法放在类的内部，这样外部也就不用去获取类的内部结构。
第7章 错误处理
- 别返回null值
返回一个null对象，在其中定义特殊情况的处理，这样程序中就不会有很多null判断的嵌套语句。
第17章 味道与启发
G8：信息过多
通过限制信息来控制耦合度
G18：不恰当的静态方法
非静态方法有一个好处就是可以实现多态。
G27：结构甚于约定
多态代替switch的时候，每次派生类都需要实现基类的功能，但是switch分支却没有这样的要求，特别是如果有多个switch，也就是多个抽象方法的时候，这样的结构更加使人不会犯错，少写一些代码。
