（转）代码整洁之道

　　　1、有意义，名副其实：降低代码的模糊度，明确说明代码的用途；

2、避免误导：accountList的类型最好就是List；

3、避免使用多个不同之处较小的名称；

4、避免使用字母l和O，因为它们像数字1和0；

5、做有意义的区分，只有意义不同时才使用不同的名字；

6、废话是无意义的区分，是冗余；

7、使用可搜索的名称：用宏定义数字比直接用数字好，避免使用单字母变量和数字常量；

8、不必使用带类型的匈牙利标记法；

9、避免成员变量使用类名前缀；

10、类名和对象名一般都是名词和名词短语；

11、方法名一般是动词和动词短语；get,set,is前缀；

12、使用解决方案领域内的名称；

13、添加有意义的语境：使用有意义的前缀，创建一个类并将变量声明为成员变量；

14、命名要精确：不要添加无意义的语境；

函数：

---

1、短小：函数中的缩进层级不应该多于一层或者两层；

2、函数应该做一件事，做好一件事，只做一件事；

3、每个函数只有一个抽象层级，其他的交给下面的抽象层来做；

4、判断函数只做了一件事：不能分函数区段；

5、阅读代码，自顶向下规则：每个函数后面都跟着下一个抽象层的函数；

6、如何让switch只做一件事：通过类工厂创建实际类并返回父类引用，再使用抽象类（父类引用）调用实际类重写的函数；

7、使用描述性的名字；

8、函数参数：为了便于测试，应该少于2个；

9、一元函数的3种形式：

　　　　　　①询问关于参数的问题（判断），②转换参数的内容（要有返回值），③参数是个事件（无返回值）

10、如果函数超过2元：应该将其中的某些参数封装成类；

11、函数名字：动/名词形式；

12、避免使用输出参数：如果需要，应该修改所属对象的状态；

13、一个函数要么做一件事（指令），要么回答一件事（询问）；

14、使用异常代替返回错误码：这样错误代码可以从主路径代码中分离出来，避免嵌套；

15、分离try/catch块：集中在一个函数中；

注释：

---

　　1、 整洁清楚的代码比注释要好得多；

　　2、 真正好的注释就是考虑不用写注释；

　　3、 需要注释的地方：提供法律信息；解释方法的意图；提供警告信息；

　　4、 ToDo注释，提示尚未完成的工作；

　　5、 避免括号后面的注释，应当减少嵌套，写成方法；

　　6、 删掉被注释掉的代码；

　　7、 注释就是一种失败；

格式：

---

　　1、 垂直上的间隔：不同的逻辑之间用空格间隔；

　　2、 垂直上的靠近：关系密切的逻辑要靠近才会更加清晰；

　　3、 变量在离使用最近的地方声明；

　　4、 相关函数：放在一起，调用者放在被调用者的上面；

　　5、 概念相关：命名模式相同，应该放在一起；

　　6、 水平方向：以不拖动滚动条为准则；

　　7、 =，+=等前后的空格可以起强调的作用；

　　8、 缩进

　　9、 团队规则

对象和数据结构（过程式代码）：

---

　　隐藏实现关乎抽象，并不是简单的添加取值器和赋值器；

　　1、 对象和数据结构的反对称性：

　　　　过程式代码便于在不改变既有代码的同时，添加新的函数（过程）；

　　　　面向对象便于在不改变既有函数的情况下，添加新的类（对象），但是如果抽象类添加新的函数，就需要修改抽象类的所有子类；

　　2、 数据结构应该只有公共变量；对象应该只有私有变量和公有函数；

　　3、 对象暴露行为，隐藏数据；便于添加新对象类型而无需修改既有行为，同时也难以在既有的对象中添加新行为。

　　　　数据结构暴露数据，没有明显的行为；便于向既有数据结构添加新行为，同时也难以向既有函数添加新数据结构。

错误的处理：

---

　　1、 不要返回null值：这样的话调用者就要处理null，增加工作量；

　　　　解决：抛出异常或者返回特例对象；

　　2、 不要传递null值：

　　3、 异常的处理：抛出异常或者返回特例对象；如果是调用第三方api可能产生异常，可以新建一个方法或异常类将第三方api打包；

　　4、 避免使用可控异常（checked exception）：因为处理它们需要修改函数头，违反了开放-闭合原则；应该使用不可控异常（runtime exception），

保持边界整洁：（电子书缺失）

---

　　1、 学习性测试：在项目中引入第三方api的新版本，测试项目是否正常工作；

　　2、 处理边界问题方法：用新类包装第三方api；用adapter模式将我们的接口转换为第三方提供的接口；

　　　　更多设计模式：http://blog.csdn.net/qinysong/archive/2006/08/09/1041818.aspx

单元测试：

---

1、测试驱动开发，整洁的测试有助于进行代码的改动；

　　2、整洁测试的标准：可读性；

　　3、双重标准：由于运行环境的差异，测试代码和生产代码可以有不同的标准，如效率、内存等；

　　4、单个测试的断言数量应该最小化，只测试一个概念；

　　5、F.I.R.S.T规则：

　　　　F fast:测试需要频繁运行，因此要能快速运行；

　　　　I Independent：测试应该相互独立；

　　　　R Repeatable：测试应当能在任何环境中重复；

　　　　S Self-validating：自足验证，测试应该能看到成功与否的结果；

　　　　T timely：测试应该及时编写，应该恰好在生产代码之前编写；

类：

---

　　1、类的组织：自顶向下原则，变量列表（公共先于私有，静态先于实体），方法列表（工具方法紧跟在所属方法之后）；

　　2、类应该短小：类名越明确，类的职责就越清晰；

　　　　（1）每个类单一权责，只有一个修改它的原因，并与少量的其他类协同完成工作；

　　　　（2）内聚：类中含有最少的变量，且每个方法都使用每个变量，此时内聚度最高，类应该是内聚高的；

　　3、隔离修改：具体类实现细节，抽象类只呈现概念，利用接口和抽象类可以隔离因为细节的改变而带来的改变类的风险；

系统：

---

　　1、构造与应用代码应该隔离开：就好像建设大楼时，构建大楼的吊车、铲车之类的东西，在大楼投入使用时已经完全不存在一样；软件系统应该讲启动过程和启动过程之后的运行时逻辑分开，在启动过程中创建应用对象，也会存在相互的依赖。

　　　　public Service getService(){

　　　　　　return new MyServiceIml(...);

　　　　}

　　　　这种延迟化赋值的好处是：在使用对象之前不用关心这种架空构造；坏处是：必须实现这个构造方法，不然无法编译，即使这个对象在运行时永远不会被使用。

　　解决方法：

　　（1）分解main，将系统中的全部构造过程搬迁到main或者main模块中：main函数创建对象，再将对象传递给应用，应用直接使用；

　　（2）工厂，可以让应用控制实体创建的时机；

　　（3）依赖注入，控制反转IoC是依赖管理的手段，它将应用需要的依赖对象的创建权责从对象中拿出来，放在一个专注于此事的对象中，并通过依赖注入（赋值器）将依赖对象传递给应用；

　　2、扩容

　　AOP，面向方面变成。Java中三种方面和类似方面的机制：代理，纯AOP框架，AspectJ

　　　　（1）Java代理：Proxy.newInstance(被代理接口，InvocationHandler h)方法执行后，被代理类的所有方法都会被加上Handler的处理逻辑，这是简单的AOP，但是太复杂；

　　　　（2）纯AOP框架：Spring AOP（需进一步了解）

　　　　（3）AspectJ语言

　　最佳的系统架构由模块化的关注面领域组成，每个关注面均用纯Java对象实现。不同的领域之间用最不具有侵害性的方面或类方面工具整合起来。这种架构能测试驱动，就像代码一样。