1.1 要有代码

我们永远抛不掉代码，因为代码呈现了需求的细节。在某些层面上，这些细节无法被忽略或抽象，必须明确之。将需求明确到机器可以执行的细节程度，就是编程要做的事。而这种规约正是代码。

1.2 糟糕的代码

勒布朗法制：稍后等于永不(Later equals never)。

1.3 混乱的代价

1.3.1 华丽新设计

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

1.3.2 态度

程序员遵从不了解混乱风险的经理的意愿，也是不专业的做法。

1.3.3 谜题

赶上期限的唯一方法——做得快的唯一方法——就是始终尽可能保持代码整洁。

1.3.4 整洁代码的艺术

写整洁代码，需要遵循大量的小技巧，贯彻刻苦习得的“整洁感”。

编写整洁代码的程序员就像是艺术家，他能用一系列变换把一块白板变作由优雅代码构成的系统。

1.3.5 什么是整洁代码

Bjarne Stroustrup：我喜欢优雅和高效的代码。代码逻辑应当直截了当，令缺陷难以隐藏：尽量减少依赖关系，使之便于维护；依据某种分层战略完善错误处理代码；性能调至最优，省得引诱别人做没规范的优化，搞出一堆混乱来。整洁的代码只做好一件事。

Grady Booch：整洁的代码简单直接。整洁的代码如同优美的散文。整洁的代码从不隐藏设计者的意图，充满了干净利落的抽象和直截了当的控制语句。

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

Michael Feathers：我可以列出我留意到的整洁代码的所有特点，但其中有一条是根本性的。整洁的代码总是看起来像是某位特别在意它的人写的。几乎没有改进的余地。代码的作者什么都想到了，如果你企图改进它，总会回到原点，赞叹某人留给你的代码——全心投入的某人留下的代码。

Ron Jeffries：近年来，我开始研究贝克的简单代码规则，差不多也都琢磨透了。简单代码，依其重要顺序：

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

在以上诸项中，我最在意代码重复。

在我看来，有意义的命名是体现表达力的一种方式。

消除重复和提高表达力让我在整洁代码方面获益良多，只要铭记这两点，改进脏代码时就会大为改观。

减少重复代码，提高表达力，提早构建简单抽象。这就是我写整洁代码的方法。

Ward Cunningham：如果每个例程都让你感到深合己意，那就是整洁代码。如果代码让编程语言看起来像是专门为解决那个问题而存在的，就可以称之为漂亮的代码。

1.4 思想流派

书中很多建议都存在争议。或许你并不完全同意这些建议，甚至可能会强烈反对其中的一些建议。这样挺好的。我们不会做最终权威。

1.5 我们是作者

Javadoc中的@author字段告诉我们自己是什么人。我们是作者。作者都有读者。实际上，作者有责任与读者做好良好沟通。下次你写代码的时候，记得自己是作者，要为评判你工作的读者写代码。

1.6 童子军军规

让营地比你来时更干净。

如果每次签入时，代码都比签出时干净，那么代码就不会腐坏。

1.7 前传与原则

在本书中，你会发现对不同设计原则的引用，包括单一职责原则和依赖倒置原则。

1.8 小结

艺术书并不保证你读过之后能成为艺术家，只能告诉你其他艺术家用过的工具、技术和思维过程。本书同样也不能担保你成为好程序员。它不担保能给你“代码感”。它能做的，只是展示好程序员的思维过程，还有他们使用的技巧、技术和工具。