代码整洁之道

第17章 味道与启发 17.1 注释 不恰当的信息。作者、最后修改时间、SPR数等元数据不该在注释中出现。注释只应该描述有关代码和设计的技术性信息。 废弃的注释。过时、无关或不正确的注释就是废弃的注释

第14章 逐步改进 本章介绍一个开始还不错，规模扩大之后就出问题的模块，并且是如何重构的。遇到解析命令行参数的情况，如果没有工具，就得遍历传入main函数的字符串数组。比如写一个Args。你只要简单地

第十三章 并发编程 对象是过程的抽象，线程是调度的抽象。 13.1 为什么要并发 在单线程的应用中，目的与时机紧密耦合，程序员只需要通过堆栈、断定即可断定应用的状态。而并发是一种解耦策略，他帮助我们把

第十二章 迭进 12.1 通过迭进设计达到整洁目的 据Kent认为，只要遵循了下面的规则，设计就能变得简单 运行所有测试 不可重复 表达了程序员的意图 尽可能减少类和方法的数量 12.2 简单设计规则

第十一章 系统 11.1 如何建造一个城市 没有人可以掌管细节。城市里会有一组组人管理着不同的部分，有些人负责全局，有些人负责细节。软件团队也是，整洁的代码帮助我们在较低级的抽象层上达成这一目标。本章

第十章 类 10.1 类的组织 遵循标准的Java约定，类应该从一组变量列表开始。如果有公共静态常量，应该先出现。 然后是私有静态变量，以及私有实体变量。很少会有公共变量。公共函数因跟在列表变量之后。

第九章 单元测试 测试驱动开发。敏捷和TDD运动鼓舞课许多程序员编写自动化单元测试。 9.1 TDD三定律 定律一在编写不能通过的单元测试前，不可编写生产代码。 定律二只可编写刚好无法通过的单元测试，

第八章 边界 有时候我们会购买第三方包和使用开源代码或者是其他团队开发的组件系统。我们应该保持软件边界整洁的实践手段和技巧。 8.1 使用第三方代码 在接口提供者和使用者之间，存在与生俱来的张力。第三

第七章 错误处理 应该弄清楚错误处理与代码简洁的关系，许多程序代码完全由错误处理所占据的话，是非常不好的。因为到处都是凌乱的代码。 7.1 使用异常而非返回码 很久以前，很多语言都不支持异常。所以当时

第六章 对象和数据结构 将变量设置为私有(private )有一个理由：我们不想其他人依赖这些变量。我们还想在 心血来潮时能自由修改其类型或实现。那么，为什么还是有那么多程序员给对象自动添加赋 值器和

第五章 格式 你应该保持良好的代码格式。你应该选用一套管理代码格式的简单规则，然后贯彻这些 规则。如果你在团队中工作，则团队应该一致同意采用一套简单的格式规则，所有成员都要遵守。使用能帮你应用这些格式

第四章 注释 什么也比不上放置良好的注释来得有用。什么也不会比乱七八糟的注释更有本事搞乱一 个模块。什么也不会比陈旧、提供错误信息的注释更有破坏性。注释的恰当用法是弥补我们在用代码表达意图时遭遇的失败

第三章 函数 短小 函数应该短小，20行封顶。 代码块和缩进 if、else、while等，应该只有一行。 只做一件事 函数应该只做一件事 如果函数只是做了该函数名下同一抽象层上的步骤，则函数还是只做