有多少种定义，就有多少种程序员。所以我只问了一些非常知名和经验丰富的程序员。优秀程序员眼中的干净代码BjarneStroustrup，C++语言的发明者，《C++程序设计语言》（中文译本《C++程序设计语言》）的作者。我喜欢优雅高效的代码。代码逻辑要直截了当，这样就很难隐藏缺陷；最小化依赖性以使其易于维护；按照一定的分层策略改进错误处理代码；优化性能，以免引诱他人做不守规矩的优化而造成一堆混乱的到来。干净的代码做好一件事。Bjarne使用了“优雅”这个词。说得好！我的MacBook上的词典提供了以下定义：外观或举止上令人愉悦的优雅和优雅；令人愉悦的精致和简单。请注意对“快乐”一词的强调。Bjarne显然认为阅读干净的代码是一种乐趣。阅读这类代码，就像看到一个精美的手工八音盒或一辆设计精良的汽车，不禁会心一笑。Bjarne还两次提到了效率。或许这句话出自C++的发明者并不奇怪；但我不认为这纯粹是为了速度。浪费的循环既难看又不愉快。请注意Bjarne是如何描述这种难看的结果的。他用了“引诱”这个词。诚恳的说道。糟糕的代码会造成混乱！当其他人修复错误的代码时，它往往会使情况变得更糟。务实的戴夫托马斯和安迪亨特从另一个角度阐明了这种情况。他们指的是破窗理论4。窗户破损的建筑物似乎被忽视了。所以其他人已经不在乎了。他们让窗户继续破裂。最后，他还参与了破坏活动，在外墙上乱涂乱画，任由垃圾堆积。一扇破窗打开了大楼倒塌的通道。Bjarne还提到完善错误处理代码。简而言之，就是注重细节。草率的错误处理代码只是程序员忽略细节的例子之一。还有内存泄漏，还有竞争条件代码。还有不一致的命名法。结果是干净的代码，突出了对细节的关注。Bjarne总结道“干净的代码只做好一件事”。不用说，许多软件设计原则最终都归结为这句格言。所以很多人都发表过类似的言论。糟糕的代码试图做太多事情，它的意图很混乱，而且它的目的也很模糊。干净的代码力求专注。每个函数、每个类、每个模块都全神贯注于一件事，完全不受周围细节的干扰和污染。优秀程序员眼中的整洁代码GradyBooch，《面向对象的分析与设计与应用》（中译《面向对象分析与设计》）作者。干净的代码简单明了。干净的代码就像优美的散文。干净的代码从不隐藏设计者的意图，充满了干净的抽象和直接的控制语句。Grady的观点与Bjarne的观点相似，但他是从可读性的角度来定义的。我特别喜欢“干净的代码就像优美的散文”这样的想法。想想你读过的一本好书。回想一下这些词是如何在您的脑海中形成图像的！就像看电影一样，对吧？比那更多的！您还会看到那些角色，听到那些声音，体验那些情绪。阅读干净的代码自然不同于阅读指环王（中文翻译《指环王》）。但是，仍然存在相似之处。就像一本好小说一样，干净的代码应该清楚地展示所解决问题的紧张程度。它应该将紧张情绪推向高潮，用一些明显的解决方案解决问题和紧张情绪，并让读者“啊哈！它应该是！”我认为格雷迪所谓的“清晰的抽象”是一个美妙的矛盾修辞法。毕竟，酥脆几乎是“混凝土”的代名词。我的MacBook上的词典是这样定义crisp这个词的：果断、实事求是、毫不犹豫或不必要的细节。尽管有两个不同的定义，这个词传达了一个强有力的信息。代码应该说实话，而不是猜测。它应该只包含必要的内容。读者应该感受到我们的果断。优秀程序员眼中的Cleancode“老板”DaveThomas，OTI创始人，Eclipse策略教父Cleancode应该由作者以外的开发人员阅读和添加。它应该有单元测试和验收测试。它使用有意义的命名。它只提供一种方法来做一件事，而不是很多。它具有尽可能少的依赖项，并且定义明确并提供干净、最小的API。代码应该从字面上表达它的意思，因为不同的语言意味着并不是所有需要的信息都可以在代码本身中清楚地表达出来。Dave同意Grady关于可读性的看法，但有一个重要的区别。Dave断言，干净的代码可以让其他人更容易向其中添加内容。这似乎是显而易见的，但怎么强调都不为过。毕竟，可读代码和易于修改的代码是有区别的。Dave将清洁度与测试联系起来！十年前，这会让人大跌眼镜。但是，TestDrivenDevelopment已经对行业产生了深远的影响，成为了基本流程之一。戴夫是对的。没有测试的代码是不干净的。无论它多么优雅，无论它多么可读和易于理解，如果它几乎没有经过测试，它就是不干净的。Dave两次提到“尽可能少”。显然，他喜欢小块代码。其实从有软件开始，人们就在反复强调这一点。越小越好。Dave还提到代码应该按字面意思表达。这种观点来自高德纳的《文学编程》（literateprogramming）5。结论是代码应该以人类可读的方式编写。优秀程序员眼中的整洁代码MichaelFeathers，《有效处理遗留代码》（中文译本《修改代码的艺术》）作者。我可以列出我注意到的所有干净代码的特征，但有一个是最基本的。干净的代码看起来总是由真正关心它的人编写的。几乎没有改进的余地。代码的作者想到了一切，如果你试图改进它，你总会回到原点，欣赏别人给你留下的代码——用心的人留下的代码。一句话：用心。这就是本书的主题。也许添加一个副标题，如何关心代码。迈克尔一针见血。干净的代码是作者处理的代码。有人花时间让它保持简单和有条理。他们对细节有适当的关注。他们关心。优秀程序员眼中的整洁代码RonJeffries，《ExtremeProgrammingInstalled》（中文译《极限编程实施》）和《ExtremeProgrammingAdventuresinC#》（中文译《C#极限编程探险》）的作者。Ron开始在战略空军司令部编写Fortran程序，此后几乎在每台机器上用每一种语言编写代码。他的话值得细细品味。这几年开始研究Baker的简码规则，差不多都想通了。简单的代码，按重要性排序：可以通过所有测试；没有重码；体现了系统中的所有设计理念；包括尽可能少的实体，例如类、方法、函数等。在以上各项中，我最关心的是代码重复。如果同一段代码重复出现，说明一个想法在代码中没有很好的体现。我尽力找出它是什么，然后尝试更清楚地表达它。在我看来，有意义的命名是一种表达方式，我经常修改几次才最终确定名称。使用像Eclipse这样的现代编码工具，重命名很便宜，所以我不介意。然而，表达力不仅仅体现在命名上。我还检查对象或方法是否试图做太多事情。如果对象的功能太多，最好将其拆分为两个或多个对象。如果方法的功能太多，我总是用ExtractMethod来重构它，从而得到一个能清楚说明自己功能的方法，以及另外几个说明如何实现这些功能的方法。删除重复和提高表现力在干净代码方面帮助了我很多，在改进脏代码时记住这两个可以产生巨大的差异。然而，我经常注意的另一个规则并不那么容易解释。这些年来，我发现所有的程序都是由非常相似的元素组成的。例如“在集合中查找某物”。无论是员工记录的数据库、名称-值对的哈希表，还是某种项目的数组，我们都会发现自己想要从集合中找到特定的项目。一旦发生这种情况，我通常会将实现封装到更抽象的方法或类中。这样做有很多好处。您可以使用一些简单的方法（例如哈希表）来实现此功能。由于搜索功能的引用指向了我的小抽象，你可以根据需要修改实现方法。这允许快速前进，同时允许未来的修订。此外，集合抽象经常提醒我注意“真正”发生的事情并避免实施任意集合行为，因为我真正需要的只是一些简单的查找方法。减少重复代码，提高表现力，尽早构建简单的抽象。这就是我编写干净代码的方式。罗恩仅用几段话就概括了本书的全部内容。不重复代码，只做一件事，表现力，小范围抽象。我拥有我需要的一切。优秀程序员眼中的整洁代码WardCunningham，Wiki的发明者，eXtremeProgramming（极限编程）的联合创始人，Smalltalk语言和面向对象的思想领袖。所有关心代码的人的教父。如果每个例程对您来说都非常个人化，那就是干净的代码。如果它使编程语言看起来像是为了解决该问题而存在，那么就称它为漂亮的代码。这个说法很沃德。它教你点头并继续倾听。如此有道理，如此简单，从不故作高深。你可能认为这就是你所说的。细看。“……非常符合我自己的意愿”。您最后一次看到喜欢的模块是什么时候？大多数模块都很复杂，对吧？这不是违反规则吗？您是否也努力捕捉散布在整个系统中的线索并将它们编织到您正在阅读的那个模块中？你最后一次阅读一段代码并像点头赞同Ward的陈述一样点头是什么时候？Ward希望您不会对干净的代码感到震惊。你不需要太多的努力。该代码正是您想要的。它清晰、简单且功能强大。每个模块都为下一个模块做准备。每个模块都会告诉您下一个模块会是什么样子。一个简洁的程序是如此之好，以至于您甚至都不会注意到它。设计师使它像任何其他设计一样简单。沃德关于“美”的说法又如何呢？我们都面临这样的困境，即语言不是为它要解决的问题而设计的。但是沃德的论点把球踢回给了我们。他说，漂亮的代码让编程语言看起来像是为了解决这个问题而存在！因此，我们有责任让语言变得简单！当心，语言是顽固的！是程序员让语言变得简单。
