代码整洁

这是本有关编写好程序的书，它充斥着代码。我们需要从各个方面来考察这些代码。从顶向下，从里而外。读完之后就知道许多关于代码的事了。

而且，我们还能说出好代码和糟糕代码之间的差异。我们将知道如何写出好代码，我们也会知道，如何将糟糕代码改成好代码。

要有代码

有一种观点，随着自动化发展，人工智能技术的进步，代码是可以自动生成，而不再需要人工编写。

而问题在于，代码呈现了需求的细节，在某些层面上，这些细节无法被忽略和抽象，并且将需求明确到机器可以执行的细节程度，这就是编程所做的工作。

即使是人类，也造不出满足客户模糊感觉的成功系统。我们永远无法抛弃必要的精确性–所以代码永存。

糟糕的代码及混乱的代价

随着混乱的增加，团队生产力也持续下降，趋向于零。当生产力下降的时，管理层只能增加更多的人手到项目中，期望提高生产力，可是新人并不熟悉系统的设计，也搞不清楚什么样的修改更符合设计的意图，什么样的修改违背设计意图。于是制造了更多的混乱。

作为程序员应有态度

很多时候讲问题归咎于经理，客户，其实他们期望从我们这里得到必要的信息，然后才能做出程度和保证，即便他们没有开口问，我们也不应该羞于告知自己的想法。对于项目的规划我们脱不了干系，并对失败负有责任，特别是当失败与糟糕的代码有关时！

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

还需要注意的是，在项目开发中，制造混乱无助于赶上工期，混乱只会拖慢你，叫你错过期限。赶上期限的唯一方法–做得更快的方法–就是始终极可能的保持代码的整洁。

代码整洁的艺术

写整洁代码，需要遵循大量的小技巧，贯彻刻苦习得的“整洁感”。这种“代码感”就是关键所在。简而言之，==编写整洁代码的程序员就像是艺术家，他能用一系列变换把一块白板变作由优雅代码构成的系统==。

什么是整洁代码

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

优雅的定义：外表或举止令人愉悦的优美和雅观；令人愉悦的精致和简单。

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

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

整洁的代码简单直接，整洁代码如同优雅的散文，整洁的代码从不隐藏设计者的意图，充满干净利落的抽象和直截了当的控制语句。
Grady Booch 《面向对象分析与设计》作者

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

能通过所有测试

没有重复代码

体现系统中全部的设计理念

包括尽量少的实体，比如类，方法，函数等
在以上诸项中，我最在意代码重复，如果同一段代码反复出现，就表示某种想法未在代码中得到良好表现，我尽力去找出到底那是什么，然后再尽力清晰地表达出来。
在我看来，有意义的命名是体现表达力的一种方式；如果对象功能太多，最好是切分为两个或多个对象；如果方法功能太多，我总是使用抽象手段重构之，从而得到一个较为清晰地说明自身功能的方法。以及另外数个说明如何实现这些功能的方法。
这么多年下来，我发现所有的程序都由极为相似的元素构成，例如“在集中中查找某元素”，不管是员工记录数据库，还是哈希表，或者是数组。我们都会发现自己想要从集合中查找某一特定条目，一旦出现这种情况，我通常会把实现手段封装到更抽象的方法或者类中
Ron Jeffries 《C#极限编程探险》作者

小结

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

和艺术书一样，本书也充满细节。代码会很多，你会看到好代码，也会看到糟糕的代码。你会看到糟糕的代码如何装换成好代码。你会看到启发、规则和技巧的列表。你会看到一个又一个例子。但这始终取决于你。