《代码整洁之道》- 小结 / we are Code Monkey

一群猴子在森林上窜下跳，抓着几个酸桃子，得意洋洋的坐在树上，确对自己造成的混乱熟视无睹。

一 序

---

没错，我们就是这么一群(Code)代码(Monkey)猴子。当我们在编写出“可以运行”的程序后，我们便得意洋洋的进入下一个任务，任由这些程序在我们眼皮底下腐烂，造成混乱。

Code Monkey

对于自己造成的混乱迟早都要付出高昂的代价去修复，与其这样，我们还不如在编码的时候就编写“干净的代码”。对于这些“干净的代码”，我们可以遵循软件开发中的5S原则：

• 整理：命名的规范
• 整顿：把你的代码放在它应该在的地方
• 清楚：整洁代码
• 清洁：代码风格、实践手段
• 身美：不断改进

所有的原则都是为了遵循 “童子军军规” —— 让营地比你来的时候更整洁

二 整洁的代码

---

整洁的代码没有固定的标准，但有大体上的原则来规范代码（代码在我们离开时要比发现时更整洁）：

• 可以让阅读代码的人感到愉悦 —— 可读性
• 代码的质量
• 好的命名
• 只做一件事
• 减少依赖关系
• 可以通过所有测试
• 没有重复代码
• 包括少量的实体

三 有意义的命名

---

一个好的命名并不一定是一开始就写好的，它是不断被更好的名称所替代的。一个好的命名遵循下列的规范：

• 名副其实：不需要被注释也应该被理解、看懂。一个名副其实的命名可以告诉读者：
• 怎么用
• 做什么事
• 为什么存在
• 避免误导：（I 、O），这到底是 I 还是 1,是 O 还是 0；（傻傻分不清）
• 做有意义的区分：
• 不要使用 a1 a2 a3
• 不要说废话（student 就不要再写成 studentInfo / studentData 了）
• 使用读得出来的名称：你应该不想让你的小伙伴一个方法名一个字母一个字母的读出来吧
• 使用可搜索的名称：不要使用硬编码，尽量使用常量替代
• 一致的命名规则：比如查找都用 find*
• 不要使用双关语

四 函数

---

还记得你曾经写过的几百行代码的函数嘛，现在在回去看看

所以写出一手干净的函数/方法代码是非常重要的，这关系到你写完代码之后会被多人(xian)“夸”(qi)的问题，对于整洁的函数：

• 短小：
• 20 行以内，不能再多了
• if / else /while 代码块理应只该有一行代码
• 每个函数/方法只干一件事（同一层级）
• 使用描述性的名称
• 函数参数：
• 一元参数：有输入应该也有输出
• 二元参数：尽量不要使用，除非参数是有序组成的(new Point(x,y))
• 三元+参数：封装成类在传过去吧
• 标识参数：不要传过来，这是在违反一个函数/方法只干一件事的原则
• 使用异常替代返回码
• 抽离 try-catch
• 别重复自己

五 注释

---

回想当初，年轻的我们还在比看谁写的注释多，注释多的更好。现在再看看当初写的代码，这是哪个程(da)序(sha)员(bi)写的注释，多久没维护了都。现在回过头想想，当初写注释的目的是为了让读者更好的了解该函数的意义，而事实上，真正好的注释就是想办法不去写注释，一切尽在函数名称上。除了好的注释，其它的都是不(la)好(ji)的注释：

• 法律信息
• 提供信息的注释（时间格式...）
• 对意图的解释
• 警告
• TODO
• 公共 API

六 格式的目的

---

格式的最大好处就是可以提高可读性，方便维护和拓展。代码的格式可以分为：

垂直格式

• 概念间垂直方向上的间隔（空一行）
• 垂直方向上的靠近（紧密联系的代码放在一起，不要隔开）
• 垂直距离
• 变量声明：靠近其使用位置
• 实体变量：类的顶部
• 相关函数：调用者放在被调用者的上方（靠近）

横向格式

• 根据是否紧密相关进行：
• 隔离（等号两边加空格）
• 靠近：（乘号两边不加空格）
• 空范围：将; 换行

while(...)
;

七 对象和数据结构

---

数据抽象应该尽可能的以抽象的形态表述数据，避免暴露过多的细节。
墨忒耳律(The Law of Demeter)：每个单元/对象/方法应当对其它单元只拥有有限的了解。

在对象 O 的 M 方法中，只应该访问：

• 对象 O 本身
• M 方法的参数
• M 方法中创建或实例化的对象
• 对象 O 直接的组件对象
• 在 O 的范围内可被全局访问的全局变量

八 单元测试

---

TDD 三定律

• 在编写不能通过的单元测试之前，不可编写生产代码
• 只可编写刚好无法通过的单元测试，不能编译也算不通过
• 只可编写刚好足以通过当前代码的生产代码

整洁的测试可读性（构造、测试、校验）一定是非常高的，在单元测试中一般将相关联的语句和断言放在一起。整洁的测试遵循 F.I.R.S.T. 规则:

• 快速
• 独立：测试之间不该有相互依赖
• 可重复：任何环境下都能跑
• 自足验证
• 及时：测试代码先于生产代码编写

九 类

---

函数应该足够短小，类也应该足够短小。且类应该

• 遵守单一权责原则：一个类应该只有一个加以修改的理由（一个抽屉只放同一类物品）
• 保持高内聚：类中应该只有少量的实体变量，且类中的每个方法都应该操作该实体

看完《代码整洁之道》不禁感叹，代码原来应该这么写，自己原来写的代码真的是太(T)难(M)看(chou)了。但是感觉还不够，还应该有更多的整洁之道，在看《重构》的时候希望能有更大的启发。