《代码整洁之道》感悟

1、类

代码顺序

看代码时自上而下，像在读报纸，依次是：

 1、公共静态常量 public static final

 2、私有静态常量 private static final

 3、私有实体变量 private field

 4、公共方法 public method

 5、私有方法 private method

命名规范

 名词，应当清晰描述类的权责，如果类名模糊，说明类的权责不清，需要拆分。

设计原则

 总体：短小；单一职责；只有一条加以修改的理由 （开闭，单一职责，依赖倒置）

1、单一职责
  系统应该由很多短小的类而不是少量的巨大的类组成，每一个小类封装一个权责，只有一个修改的原因，并与少数其它类一起协同达成期望的行为。

2、高内聚
  类应该只应有少数实例变量；类中每个方法都应操作这些实例变量，方法操作得越多，就越粘到类上，内聚性就越高。内聚性高意味着类中的方法和变量互相依赖，互相结合成一个逻辑整体

2、函数

  总体：每个函数依序把你带到下一函数

具体规则

1、短小：20条封顶最佳

2、只做一件事

  如何判断是否只做了一件事？
   a. 做的事在同一抽象级
   b. 不能再拆分出函数

3、每个函数都在一个抽象级

4、将switch语句埋藏在比较底层，如抽象工厂模式

5、使用描述性的名称

   与模块名一脉相承的名称

   动词+名词 如：queryUserInfo

   类名 + 函数名能连成一个通顺的句子

6、入参个数越少越好，不超过3个

   why？ 单测路径覆盖随入参个数指数增加

   解决：参数多了封装成类

3、注释

目标

  最好的代码应该是自解释的，无需注释

经典语录

   “别给糟糕的代码加注释，重写吧”

   “注释是一种失败，为了掩饰糟糕的代码”

   ”注释会撒谎：注释存在的时间越久，离代码的含义越远”

坏注释

  坏注释是糟糕代码的借口

  多余的注释：不能比代码提供更多的信息

  废话注释：代码修改后可能变为误导性注释

  误导性注释

  版本性注释和归属注释都交给VCS吧

  注释掉的代码，别人不敢删，有VCS了随便删

好的实践

  短函数取好名字，一目了然，无需注释

  定期删除不需要的TODO

  公共API编写良好的javadoc