一群猴子在森林上窜下跳，抓着几个酸桃子，得意洋洋的坐在树上，确对自己造成的混乱熟视无睹。
一 序
没错，我们就是这么一群(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)了。但是感觉还不够，还应该有更多的整洁之道，在看《重构》的时候希望能有更大的启发。
