取名篇
1.类名和对象名应该是名词或名词短语。如customer,account。避免使用Manager，Processor这样的类名。
2.方法名应当是动词或动词短语。如：postPayment,deletePage或save。属性访问器，修改器和断言应该根据具体命令，并依照javaBean的标准，加上get,set和is前缀。
3.重载构造器时，使用静态工厂好于直接使用构造器。例如：
User user =new User("张三")
User user =User.name("张三");
在其他书上也有提及这个，具体哪本书就忘了。
4.不要用谚语，梗来当方法名。方法名要做到言到义到。（方法名这个很重要，好的名字应该做到看方法名就知道这个方法具体做什么）
5.一词一意。比如add，可以表示String的字符串拼接，又可以表示新增某个事物到数据库。那么你就可以用insert来表示新增到数据库。
函数篇
1.函数应该短小精干！
2.基于短小精干之后，函数应该只做一件事情。做好这件事情。只做这一点事情。
3.函数名称的关键在于描述性，而不是长短。
4.函数的参数应该尽可能的少。
4.1比如一元函数很好理解，因为只有一个参数。
4.2二元函数例如：appendStr(a,b)，两个参数同为一个类型，你能知道哪个是要追加的字符串，一个是被追加的字符串么。所 以文中提及有条件的话可以把二元函数转为一元函数，如上例子可以改为，a.appendStr(b)。
4.3三元函数就更加复杂了，相信大家也一定也有过放错参数位置的经历。
文中也提及如果有三个或三个以上的参数，就可以把参数封装为类了。
5.函数名应该为动词，标示做什么的。
6.一个函数应该只做一个事情。文中的例子我觉得很好。它讲述的是 一个检查账号密码的方法，函数名叫checkPassword，返回boolean。我们在习惯的会在账号密码校验成功后把用户存入session，因此例子也不例外。但是这就违反了单一职责原则，也就是函数应该只做一件事，最好一件事。这样造成的后果是，如果我们信了这个方法名仅仅是检查账号密码，那么他可能会抹去现在正进行的session。
7.抽离try,catch代码块。可以把try/catch里面的代码抽离成一个方法。这样便于修改和方便阅读。
7.1 插一个小话题，关于为什么要用异常类。返回错误码的话，一般会有个专门定义所有异常code的常量类或者枚举类。这样的话如果要新增异常就会重新编译部署所有引入这个常量类或者枚举类。造成了负面压力。如果用异常类，就无需编译或重新部署、这也是文中提及到的地方。
小结：写函数时，一开始都冗长而复杂。有太多的缩进和嵌套循环。有过长的参数列表。名字是随便取得，也会有重复的代码。不过我会配上一套单元测试，覆盖每行丑陋的代码。然后我打磨这些代码，分解函数，修改名称，消除重复。我缩短和重新安放方法。有时我还拆散类。同时保持单元测试。我并不从一开始就按照规则写函数。我想没人能做到。
注释篇
作者并不认同代码中用巨量的注释来表达代码的含义。作者更希望用让代码具有表达力来阐述其行为。
1.公共API应该具有详细描述的注释，但JAVADoc也有可能误导，不适用或者提供错误信息。
数据结构篇
这篇主要就介绍了为什么要用DO（数据库表结构类），以及不应该在这类对象里面加上业务方法。
错误处理篇
本篇将带领大家编写出整洁又强固的错误处理代码以及一些技巧和思路。
1.使用异常而非返回码
2.考虑使用特例对象（特例模式）
3.函数不要返回null值
4.不要传递null值
边界
如何将外来代码干净利落的放入自己的代码中。
1.运用好外来代码的测试。
2.文中提出了可以用适配器模式来接入外来的代码。
整洁的测试
文章中只是粗略的提及了整洁测试的方法，具体我觉得还可以再去找本驱动测试的书看看。文中提倡驱动测试的方法，这样做的好处有。
1.测试拥有全部的覆盖率，保证每个生产代码的正确。
2.可以大胆的重构代码，因为有测试的覆盖，不用畏畏缩缩的。
坏处：测试代码同生产代码一样多，维护要维护两份代码。
