序#

“小处诚实非小事”、” 神在细节之中 “。

开发者通过小型实践获得可用于大型实践的技能和信用度。

5S 原则体系：整理、整顿、清楚、清洁、身美。

前言#

当事态变得严重起来时，如何保证我们在那道正确的门后做补救工作？答案是：技艺。

学习技艺有两点：知和行。学习有关原则、模式和实践的知识，穷尽应知之事，并且要对其了如指掌，通过刻苦实践掌握它。

尝试去理解自己对阅读和修改代码的反应，尽力了解为什么会有这样的感受、为什么会如此行事。总结一套描述在编写、阅读、清理代码时思维方式的知识库。

第一章 整洁代码#

将需求明确到机器可以执行的细节程度，就是编码要做的事。

勒布朗法则：稍后等于永不。

混乱的代价：随着混乱的增加，团队生产力也持续下降，以致于趋向于零。

花时间保持代码整洁不但关乎效率，还关乎生存。

多数经理想要好代码，即便他们总是痴缠于进度。程序员遵从不了解混乱风险的经理的意愿，是不专业的做法。

做得快的唯一方法就是保持代码整洁。

“我喜欢优雅和高效的代码。代码逻辑应当直接了当，令缺陷难于隐藏；尽量减少依赖关系，使之便于维护；依据某种分层战略完善错误处理代码；性能调至最优，省得别人做没规矩的优化，搞出一堆混乱来。整洁的代码只做好一件事”——Bjame Stroustrup,C++ 语言发明者。

整洁的代码力求集中，每个函数、每个类和每个模块都全神贯注于一事，完全不受四周细节的干扰和污染。

代码应当陈述事实，不引人猜测。

“整洁的代码因可由作者之外的开发者阅读和增补。它应当由单元测试和验收测试。它使用由意义的命名。它只提供一种而非多种做一件事的途径。它只有尽量少的依赖关系，而且要明确地定义和提供清晰的、尽量少的 API。代码应通过其字面表达含义，因为不用的语言导致并非所有必须得信息均可通过代码自身清晰表达”——Dave Thomas

简单代码，依其重要顺序：

• 1. 能通过所有测试

• 2. 没有重复代码

• 3. 体现系统中全部设计理念

• 4. 包括尽量少的实体，比如类、方法、函数等

有意义的命名。减少重复代码，提升表达力，提早构建简单抽象。

童子军军规：让营地比你来时，更干净。

第二章 有意义的命名#

名副其实、避免误导、做有意义的区分、使用读得出来的名称、使用可搜索的名称、避免思维映射。

类名：类名和对象名应该是名词或名词短语。

方法名：方法名应当是动词或动词短语。

每个概念对应一个词。别用双关语。

使用解决方案领域名称，添加有意义的语境。

只要短名称足够清楚，就比长名称好。

第三章 函数#

短小、代码块和缩进、只做一件事、每个函数一个抽象层级、使用具有描述性的命名。

命名方式要保持一致。

函数参数：理想没有参数，其次是一个，再次是两个，应避免三个。

参数对象：从参数创建对象，从而减少参数数量，看起来像是在作弊，但实则并非如此。

查询与修改分开。

使用异常替代返回错误码。

结构化编程：每个函数都只有一个入口、一个出口。

代码写两遍：一遍实现功能，一遍完善代码。

第四章 注释#

“别给糟糕的代码加注释 —— 重新写吧”——Brian W.Kernighan 与 P.J.Plaugher

注释存在的时间越久，离所描述的代码就越远。

注释不能美化糟糕的代码。

坏注释：喃喃自语、多余的注释、误导性注释、寻规式注释、日志式注释、废话注释

第五章 格式#

你应该保持良好的代码格式。应该选用一套管理代码的简单规则，然后贯彻这些规则。

第六章 对象和数据结构#

私有变量：不想让其他类依赖这些变量。

得墨忒耳律：模块不应该了解它所操作对象的内部情形。

数据传送对象：DTO

对象暴露行为，隐藏数据，便于添加新对象类型而无须修改既有行为，同时难以在既有对象中添加新行为；数据结构暴露数据，没有明显的行为，便于向既有数据结构添加新行为，同时难以向既有函数添加新数据结构。

第七章 错误处理#

当错误发生时，程序员就有责任确保代码照常工作。

使用异常而非返回码

先写 try-catch-finally 语句

定义常规流程

别返回 null 值、别传递 null 值

第八章 边界#

边界上的代码需要清晰的分割和定义了期望的测试。

第九章 单元测试#

TDD 的三项法则：

• 1. 在编好失败单元测试之前，不要编写任何产品代码。

• 2. 只要有一个单元测试失败嘞，就不要再写测试代码；无法通过编译也是一种失败的情况。

• 3. 产品代码恰好能够让当前失败的单元测试成功通过即可，不要多写。

保持测试代码整洁

无论设计划分多好，如果没有了测试，你就很难做改动，因为你担忧改动引入不可预知的缺陷。

整洁测试的规则：快速、独立、可重复、自足验证、及时

第十章 类#

单一权责原则、内聚、隔离修改

SOLID 原则

第十一章 系统#

“复杂要人命，它消磨开发者的生命，让产品难以规划、构建和测试”–Ray Ozzie

在所有的抽象层级上，意图都应该清晰可辨。

第十二章 迭进#

测试驱动开发。

重构：提升内聚性，降低耦合度，切分关注面，模块化系统性关注面，缩小函数和类的尺寸，选用更好的名称，消除重复，提升表达力，尽可能减少类和方法的数量。可以参考：重构：改善既有代码的设计

你的职责是维护一套便于维护的整洁代码。

第十三章 并发编程#

并发：

• 1. 并发会在性能和编写额外代码上增加一些开销

• 2. 正确的并发是复杂的，即便对于简单的问题也是如此

• 3. 并发缺陷并非总能复现

• 4. 并发常常需要对设计策略做根本性修改

并发防御原则：

• 1. 单一权责原则

• 2. 限制数据作用域

• 3. 使用数据副本

• 4. 线程应尽可能独立
  原文链接：代码整洁之道：神在细节之中

本作品采用《CC 协议》，转载必须注明作者和本文链接