代码整洁之道

第一章 整洁代码

代码逻辑直截了当，减少依赖关系，依据某种分层战略完善错误处理代码，性能调至最优

• 能通过所有测试；
• 没有重复代码；
• 体现系统中的全部设计理念；
• 包括尽量少的实体，比如类、方法、函数等。

第二章 有意义的命名

• 名副其实：变量、函数或类名称能告诉你，它为什么会存在，它做什么事。应该怎么用。
• 避免误导：避免使用与本意相悖的词；避免使用专有名词；避免使用不同之处较小的名称
• 有意义的区分
• 使用读得出来的名称
• 使用可搜索的名称
• 避免使用编码
• 避免思维映射：不应当让读者在脑中把你的名字翻译为他们熟知的名称
• 类名和对象名：名称或名词短语
• 方法名：动词或动词短语
• 不用俗语或俚语
• 每个概念对应一个词
• 不用双关语
• 使用解决方案领域名称
• 使用源自所涉及问题领域的名称
• 添加有意义的语境

第三章 函数

• 短小：20行封顶
• 只做一件事
• 每个函数一个抽象层级：自顶向下读代码，每个函数后面都跟着位于下一抽象层级的函数
• switch语句：确保每个switch都埋藏在较低的抽象层级，而且永远不重复
• 使用描述性的名称：命名方式要保持一致，使用与模块名一脉相承的短语、名词和动词给函数命名。
• 函数参数：参数数量越少越好 ，尽量避免三参数函数
• 无副作用
• 分隔指令与询问：函数应该修改某对象的状态（指令），或是返回该对象的有关信息（询问）。
• 使用异常代替返回错误码：抽离try/catch代码块，错误处理抽出单独一个函数
• 别重复自己：尽量减少重复代码

第四章 注释

• 注释不能美化糟糕的代码：带有少量注释的整洁而有表达力的代码，要比带有大量注释的零碎而复杂的代码像样的多。
• 用代码来阐述
• 好注释：
  1. 法律信息：例如，版权及著作权声明就是必须和有理由在每个源文件开头注释处放置的内容
  2. 提供信息的注释：提供了有关实现的有用信息
  3. 对意图的解释：提供了某个决定后面的意图
  4. 阐释：注释把某些晦涩难明的参数或者返回值的意义翻译为某种可读形式
  5. 警示
  6. TODO：是一种程序员认为应该做，但由于某些原因目前还没做的工作。
  7. 放大：注释可以用来放大某种看来不合理之物的重要性。
  8. 公共API中的JAavadoc
• 坏注释

第五章 格式

• 垂直格式：垂直方向上要有区隔（函数之间空白行）；靠近的代码暗示它们之间的紧密关系；自上向下展示函数调用依赖顺序，被调用的函数应该放在执行调用的函数下面。
• 横向格式

第六章 对象和数据结构

• 数据抽象：类并不简单地用取值器和赋值器将其变量推向外间，而是曝露抽象接口，以便用户无需了解数据的实现就能操作数据本体。
• 数据、对象的反对称性：过程式代码（使用数据结构的代码）便于在不改动既有数据结构的前提下添加新函数。面向对象代码便于在不改动既有函数的前提下添加新类。
• 得墨忒耳律：模块不应了解它所操作对象的内部情形。方法不应调用由任何函数返回的对象的方法。
• 数据传送对象：一个只有公共变量、没有函数的类的最为精练的数据结构。或DTO(Data Transfer Objects)将原始数据转换为数据库的翻译

第七章 错误处理

• 使用异常而非返回码
• 先写Try-Catch-Finally语句
• 使用不可控异常
• 给出异常发生的环境说明：抛出的每个异常，都应当提供足够的环境说明，以便判断错误的来源和处所。
• 依调用者需要定义异常类：考虑异常如何被捕获。
• 定义常规流程：创建一个类或配置一个对象，用来处理特例（特例模式）。
• 别返回null值
• 别传递null值

第八章 边界

• 使用第三方代码：如果使用类似Map这样的边界接口，就把它保留在类或近亲类中。避免从公共API中返回边界接口，或将边界接口作为参数传递给公共API
• 浏览和学习边界
• 学习性测试的好处不只是免费：一种精确试验，帮助我们增进对API的理解。
• 使用尚不存在的代码
• 整洁的边界：边界上的代码需要清晰的分割和定义了期望的测试。避免我们的代码过多地依赖第三方代码中的特定信息。

第九章 单元测试

略

第十章 类

• 类的组织：类应该从一组变量列表开始。封装。
• 类应该短小：
  1. 单一权责原则（SRP）认为，类或模块应有且只有一条加以修改的理由。
  2. 内聚：类应该只有少量实体变量。类中的每个方法都应该操作一个或多个这种变量。
  3. 保持内聚性就会得到许多短小的类
• 为了修改而组织：隔离修改

第十一章 系统

• 将系统的构造与使用分开
  1. 分解main：将全部构造过程搬迁到main或被称之为main的模块中，设计系统的其余部分时，假设所有对象都已正确构造和设置。
  2. 工厂：使用工厂模式让应用自行控制何时创建实体，但构造的细节却隔离于应用程序代码之外。
  3. 依赖注入：控制反转在依赖管理中的一种应用手段。控制反转将第二权责从对象中拿出来，转移到另一个专注于此的对象中，从而遵循了单一权责原则。
• 扩容：横贯式关注面：原则上，可以从模块、封装的角度推理持久化策略。实践上，却不得不将实现了持久化策略的代码铺展到许多对象中。
• Java代理：适用于简单的情况，例如在单独的对象或类中包装方法调用。
• 纯Java AOP框架：编程工具能自动处理大多数代理模板代码。
• Aspect J的方面：通过方面来实现关注面切分的功能最全的工具是Aspect J语言，一种提供“一流的”将方面作为模块构造处理支持的Java扩展
• 测试驱动系统架构

第十二章 迭进

• 运行所有测试：确保系统完全可测试能帮助我们创建更好的设计。测试消除了对清理代码就会破坏代码的恐惧。
• 重构：消除重复，保证表达力，尽可能减少类和方法的数量。
• 不可重复
• 表达力：代码应当清晰地表达出其作者的意图。
• 尽可能少的类和方法：保持函数和类短小的同事，保持整个系统短小精悍。（优先级最低）