软件质量, 不但依赖于架构及项目管理, 而且与代码质量紧密相关。
本书主要讲述了代码质量与其整洁度成正比的道理, 并由此揭示代码整洁之道。
干净的代码, 既在质量上较为可靠, 也为后期维护、升级奠定了良好基础。

Code Monkey: 以为自己能够写出一些代码就沾沾自喜, 看着自己写的”可以运行” 的代码, 竟然还自豪不已。

代码整洁的前提:

  • 代码大部分时候是用来维护的, 而不是用来实现功能的
  • 优秀的代码大部分是可以自描述的, 好于文档和注释
  • 设计模式只是手段, 代码清晰才是目的

整洁代码的途径:

有意义的命名:

  • 名副其实——最好要腾出时间来考虑属性或方法的命名, 而不是随便给属性和方法取一个没有具体意义的名称
  • 避免误导——使用明确的区分度较大的命名, 避免用会引起误解的.譬如O、l这种命名法
  • 做有意义的区分——尽量使用明确的描述内容的名称来定义类和属性, 避免类似 info、data、Object 此类的命名方式
  • 使用读的出来的命名方式——不要使用缩写在代码中进行命名
  • 使用可搜索的名称——使用静态常量代替代码中的常量
  • 避免思维映射——不要用自己的思维映射方式来揣测其他人对于命名的理解
  • 类名——类是用来描述一种具体事物的, 不应当是一个动词
  • 方法名——方法是用来描述某一事物的某一动作的, 应当是动词或者是动词短语
  • 别用双关语——在同种类型的操作中采用同样的方法名, 如果操作有所不同或者是实现或者是原理有所不同, 请使用不同的方法重新命名
  • 使用计算机术语进行命名或者是问题领域的名称进行命名, 这样能够使得下一个读代码的人能够清楚的知道代码的意义

函数: 一个方法做且只做一件事, 并且短小到不能再抽取方法为止

  • 只在一个抽象层级——注意函数在抽象层级上面占据的位置不要跃层
  • Switch ——使用工厂和接口的模式来掩盖 switch 函数
  • 使用描述性的名称——使用有意义的函数名称, 并且尽量的明确
  • 函数参数——输入的参数尽量少
    ① 一元函数的普遍形式——如果函数要对输入参数进行转换操作, 转换结果就该体现为返回值. 不要使用 boolean 作为输入参数
    ② 二元函数——尽量避免, 除非是单个值的有序组成部分, 类似 new Point(0,0)
    ③ 三元函数——尽量避免, 免不了可以使用新的类进行封装
  • 动词与关键字——函数名字应体现函数动作和参数的关系, 譬如 writeField(name)
  • 无副作用——注意函数只做一件事, 尽量避免做除了函数名能描述之外的其他任何操作
  • 输出参数——不要将输入参数当作输出参数来用
  • 分隔指令和询问——避免出现这种情况, 一个函数动作如果成功返回A, 失败返回B, 然后进行判断, 我们可以通过 try/catch 进行处理
  • 使用异常替代返回错误——充分利用 java 的错误处理机制来进行编程
  • 抽离 try/catch —— try/catch 中的每一块内容应该就是一个独立的事（函数）
  • 别重复自己——使用面向对象的方法将代码集中到基类避免冗余
  • 结构化编程——如果函数足够短, 出现 return, break, continue 并没有什么错
  • 怎么做——我们不可能一次性就把代码写成这样, 所以我们可以慢慢的通过不断的重构来慢慢优化我们的代码结构

注释: 需要注释本身就是一种失败, 真正可读性非常好的代码不需要注释, 但是由于一般的局限性我们还是需要注释, 那我们尽量把注释写的好些

  • 不要太过相信注释, 代码才是对于客观现实最直观的解释.
  • 好的注释——对于意图的解释, 对于晦涩的代码的阐释, 对于关键内容的警告, TODO 改写没有写的代码
  • 坏注释——由于SVN 等代码版本控制的出现, 循规式的注释、日志式注释、归属于署名

格式: 垂直格式, 自上向下; 水平格式, 尽量短；符合团队统一代码风格

  • 变量声明: 变量声明尽量靠近其使用位置
  • 实体变量: 应该在类的顶部声明
  • 相关函数: 若某个函数调用了另外一个, 应放到一起, 调用者尽可能放在被调用者上边
  • 概念相关: 概念相关的代码应放一起

类: 6大设计原则第一原则

  • 类——短小, 且描述其单一权责 SRP, 有且只有一条加以修改的理由
  • 内聚——内聚性高, 意味着, 类中方法和变量相互依赖结合成一个逻辑整体

测试驱动

  • 注意边界条件; 避免扎堆
  • 单元测试的三个阶段: 构造测试数据, 操作测试数据, 检验操作是否符合预期
  • 整洁可读性, 遵循: Fast, Independent, Repeatable, Self-Validating, Timely—快速, 独立, 可重复, 自我验证, 及时

a good unit test should be automated, repeatable, easy to understand, incremental, easy to run, and fast
一个好的单元测试应该是自动化的、可重复的、易于理解的、增量的、易于运行的、快速的.

错误处理

  • 使用异常而非返回码
  • 首先考虑 try catch finally语句
  • 使用不可控异常
  • 给出异常说明
  • 不返回 Null, collection.emptyList()方法
  • 避免传递 Null 值