代码的坏味道

转载篇

1、重复代码

即使是一两句代码的重复也需要重构，有时候重复不是那么明显，可能需要首先进行其他的重构才能看到代码重复。

2、长方法

用面向过程的思路来写干面向对象的活，即使可以在一页内能够显示的方法也可能过长

3、大类

一个类含有太多的责任和行为，违背了单一性的原则

4、参数太多

参数过多，可用对象代替

5、不一致的变化

不要把变化速度不同的东西放在一起。不要把一个方法对每个子类的变化的部分和不变化的部分放在

一起。不要把对象中每秒都在变化的实例变量和一个月才变化一次的实例变量放一起。一句话，分类。

6、限制对其他类内部结构的了解

7、改变影响到太多的类和方法，关联性太强

8、用类代替原始数据类型

9、子类很少利用父类给予他们的东西

10、注释是说明why

 

优雅代码

1、注释

    一定给常量加注释

   公共API需要添加注释，其他代码谨慎使用注释

2、命名

    尽可能使用标准命名方法，别害怕长名称，长而具有描述性的名称比短而令人费解的名称好

3、方法

    函数不应该有100行那么长，20行封顶最好。 if else while等控制语句其中代码块应该只有一行，即一个函数调用语句

    函数应该只做一件事，一个函数不应该抽象出另外一个函数

    最理想的参数是零参数，最长也不该超过三个(超过三个最好抽象为类)，尽量不要输出参数

    向函数传入布尔值用于 区分不同业务的做法不提倡，应该拆分成多个函数

    别返回null值，抛出异常或者返回特殊对象， 别传入null值

4、异常与错误

　 抽离try catch包含的代码块，其中代码块抽象为一个函数

    抛出的每个异常，都应当提供足够的环境说明，以便判断错误的来源

    不要将系统错误归咎偶然事件

5、并发

    分离并发相关代码与其他代码

　 严格限制对可能被共享的数据的访问

    避免使用一个共享对象的多个同步方法

    保持同步区域微小，尽可能少设计临界区

6、代码结构

    关系密切的代码应该相互靠近

    不要继承常量，比如接口中定义常量

    DTO是一个只有公共变量没有函数的类

    对象暴露行为，隐藏数据

    不要使用尤达表示法，如if(null == obj)  

    一般情况使用if else 简单语句使用三目运算符

7、设计

    类应该足够短小。满足单一权责原则

    类应该遵循依赖倒置原则，类应该依赖于抽象而不是依赖具体细节

    类中的方法越少越好，函数知道的变量越少越好，类拥有的实体变量越少越好

 

减少重复代码，提高表达力，提早构建，简单抽象