代码的整洁之道之独孤九剑

《代码的整洁之道》这本书非常好，具有很好的指导意义。如果从来没有写过代码，或者写的代码比较少，那么看这本书，会比较茫然，不知所云。如果有非常丰富的写代码经验，再来看这本书，就会发现，是如此的浅显易懂。总结下来，就是代码的整洁之道之独孤九剑。时不时的翻看一下要领，总会有意想不到的效果。

一、不整洁的代码，阅读体验是这样的：

• 乱（组织乱，职责乱，名称乱）
• 逻辑不清晰（if-else 太多）
• 绕弯子（简单的事情复杂化，复杂的事情无解化）
• 看不懂（只有写的人知道什么意思）
• 难修改（耦合严重，各种交叉）

二、整洁的代码，阅读体验是这样的：

• 清晰（是什么，做了什么，一眼看得出来）
• 简单（职责少，代码少，逻辑少）
• 干净（没有多余的逻辑）
• 好拓展（依赖的比较少，修改不会影响很多）

三、灵魂法则

• 稍后等于永不
• 破窗原理：窗户破损了的建筑让人觉得似乎无人照管。于是别人也再不关心。他们放任窗户继续破损。
• 最终自己 也参加破坏活动，在外墙上涂鸦，任垃圾堆积。一扇破损的窗户开辟了大厦走向倾颠的道路。

四、建立意识

• 代码质量与其整洁度成正比，干净的代码，既在质量上可靠，也为后期维护、升级奠定了良好基础。
• 编写代码的难度，取决于周边代码的阅读难度，想要快速实现需求，想要快速完成任务，想要轻松的写代码，先让你的书写的代码整洁易读。
• 保持整洁的习惯，发现脏代码就要及时纠正。花时间保持代码整洁，这不但有关效率，还有关效率的生存。
• 程序员遵从不了解混乱风险的项目经理的意愿，都是不专业的做法。
• 让代码比你来时更干净，如果每次提交时，都比原先更干净，代码就不会腐坏。
• 赶上期限的唯一方法，做得更快的唯一方法，就是始终尽可能的保持代码的整洁。

五、有意义的命名

• 设置可读性高的名称
• 有意义的区分
• 读的出来的名称
• 使用可搜索的名称
• 避免思维映射，不要让读者在脑中将你的名称译为他们熟知的名称
• 类名，不应该是动词
• 方法名，应当是动词或动词短语，取名应该言简意赅，别装可爱
• 每个概念对应一个词
• 别用双关语
• 使用解决方案领域名称
• 不要添加没用的语境

六、函数

• 短小，控制在20行左右，不要超过50行，缩进层级不该大于两层
• 只做一件事，单一职责。要判断函数是否做了不止一件事，就看它里面的代码，是否能再拆出一个函数
  每个函数一个抽象层级，
• switch语句，使用工厂模式发挥多态作用
• 使用描述性名称，长而具有描述性的名称比短而令人费解的好
• 函数的参数，超过3个参数的函数，就需要特别说明。定义的函数的参数越多，你耗费函数使用者的青春就越多，使用者需要花时间搞清楚每个参数的具体含义和顺序。最理想的参数数量是 1~2 。从测试的角度看，参数越多，可能出现的用例就越多，就越容易出错 。
• 不要有副作用，副作用就是做了名称以外的工作，不要违反只做一件事的原则
• 分割指令与询问
• 使用异常替代返回错误码
• 抽离try/catch代码块，使用错误处理代码从主路径代码中分离出来得到简化
• 错误处理就是一件事，关键try应该是这个函数的第一个单词且catch/finally后无其它内容
• 依赖磁铁，消灭错误码枚举类改用异常派生类
• 别重复自己，消除重复代码，适时封装成方法

七、被差评的注释

• 令人费解的注释，读懂花费的时间比看代码的时间还长
• 误导性注释，老旧的注释。代码才是真相，注释有可能是谎言，还是要”少写注释！
• 日志型注释。比如记录修改日志
• 废话注释。变量名、函数名已经很清晰，就不需要注释，注释里不要放一些奇怪的东西
• 注释掉的代码。没用的代码及时删除

八、注释

• 别给糟糕的代码写注释，重构！
• 提供信息的注释
• 对意图的解释
• 阐释
• 警示
• TODO 注释

九、悟