原文地址：

http://www.cnblogs.com/greeenplace/articles/4667830.html

PDF文件下载地址：

http://download.csdn.net/detail/aradin/8440247

在做IT的公司里，尤其是软件开发部门，一般不会要求工程师衣着正式。在我工作过的一些环境相对宽松的公司里，很多程序员的衣着连得体都算不上（搞笑的T恤、短裤、拖鞋或者干脆不穿鞋）。我想，我本人也在这个行列里面。虽然我现在改行做软件开发方面的咨询工作，但还是改不了这副德性。衣着体面的其中一个积极方面是它体现了对周围人的尊重，以及对所从事工作的尊重。比如，那些研究市场的人要表现出对客户的尊重。而大多数程序员基本上每天主要的工作就是和其他程序员打交道。那么这说明程序员之间就不用互相尊重吗且也不用尊重自己的工作吗/p>

程序员之间的互相尊重体现在他所写的代码中。他们对工作的尊重也体现在那里。

在《Clean Code》一书中Bob大叔认为在代码阅读过程中人们说脏话的频率是衡量代码质量的唯一标准。这也是同样的道理。

这样，代码最重要的读者就不再是编译器、解释器或者电脑了，而是人。写出的代码能

让人快速理解、轻松维护、容易扩展的程序员才是专业的程序员。

当然，为了达到这些目的，仅有编写程序的礼节是不够的，还需要很多相关的知识。这些知识既不属于编程技巧，也不属于算法设计，并且和单元测试或者测试驱动开发这些话题也相对独立。这些知识往往只能在公司无人问津的编程规范中才有所提及。这是我所见的仅把代码可读性作为主题的一本书，而且这本书写得很有趣！

翻译书是件费时费力的事情，好在本书恰好涉及我感兴趣的话题。但翻译本书有一点点自相矛盾的地方，因为书中相当的篇幅是在讲如何写出易读的英语。当然这里的“英语”大多数的时候只是指“自然语言”，对于中文同样适用。但鉴于大多数编程语言都是基于英语的（至少到目前为止），而且要求很多程序员用英语来注释，在这种情况下努力学好英语也是必要的。

尹哲

我们曾经在非常成功的软件公司中和出色的工程师一起工作，然而我们所遇到的代码仍有很大的改进空间。实际上，我们曾见到一些很难看的代码，你可能也见过。

但是当我们看到写得很漂亮的代码时，会很受启发。好代码会很明确告诉你它在做什么。使用它会很有趣，并且会鼓励你把自己的代码写得更好。

这是一本关于如何编写具有高可读性代码的书。本书的关键思想是代码应该写得容易理解。确切地说，使别人用最短的时间理解你的代码。

本书解释了这种思想，并且用不同语言的大量例子来讲解，包括C++、Python、JavaScript和Java。我们避免使用某种高级的语言特性，所以即使你不是对所有的语言都了解，也能很容易看懂。（以我们的经验，反正可读性的大部分概念都是和语言不相关的。）

每一章都会深入编程的某个方面来讨论如何使代码更容易理解。本书分成四部分：

表面层次上的改进

命名、注释以及审美——可以用于代码库每一行的小提示。

简化循环和逻辑

在程序中定义循环、逻辑和变量，从而使得代码更容易理解。

重新组织你的代码

在更高层次上组织大的代码块以及在功能层次上解决问题的方法。

精选话题

把“易于理解”的思想应用于测试以及大数据结构代码的例子。

我们希望本书读起来愉快而又轻松。我们希望大部分读者在一两周之内读完全书。

章节是按照“难度”来排序的：基本的话题在前面，更高级的话题在后面。然而，每章都是独立的。因此如果你想跳着读也可以。

本书旨在帮助你完成你的工作。一般来说，可以在程序和文档中使用本书的代码。如果你复制了代码的关键部分，那么你就需要联系我们获得许可。例如，利用本书的几段代码编写程序是不需要许可的。售卖或出版O’Reilly书中示例的D-ROM需要我们的许可。

引用本书回答问题以及引用示例代码不需要我们的许可。将本书的大量示例代码用于你的产品文档中需要许可。

如果你认为对代码示例的使用已经超出以上的许可范围，我们很欢迎你通过permissions@oreilly.com联系我们。

有关本书的任何建议和疑问，可以通过下列方式与我们取得联系：

美国：

O’Reilly Media, Inc.

1005 Gravenstein Highway North

Sebastopol, CA 95472

中国：

北京市西城区西直门南大街2 成铭大厦C座807室（100035）

奥莱利技术咨询（北京）有限公司

我们会在本书的 页中列出勘误表、示例和其他信息。可以通过http://oreilly.com/product/9780596802301.do访问该页面。

要评论或询问本书的技术问题，请发送邮件到：

bookquestions@oreilly.com

有关我们的书籍、会议、资源中心以及O’Reilly 络，可以访问我们的 站：

http://www.oreilly.com

http://www.oreilly.com.cn

在Facebook上联系我们：http://facebook.com/oreilly

在Twitter上联系我们：http://twitter.com/oreillymedia

在You Tube上联系我们：http://youtube.com/oreillymedia

我们要感谢那些花时间审阅全书书稿的同事，包括Alan Davidson、Josh Ehrlich、Rob Konigsberg、Archie Russell、Gabe W.，以及Asaph Zemach。如果书里有任何错误都是他们的过失（开玩笑）。

我们感激那些对书中不同部分的草稿给了具体反馈的很多审阅者，包括Michael Hunger、George Heinenman以及Chuck Hudson。

我们还从下面这些人那里得到了大量的想法和反馈：John Blackburn、Tim Dasilva、Dennis Geels、Steve Gerding、Chris Harris、Josh Hyman、Joel Ingram、Erik Mavrinac、Greg Miller、Anatole Paine和Nick White。

最后，我们想感谢Melissa和Suzanne，他们一直鼓励我们，并给我们创建条件来滔滔不绝地谈论编程话题。

在过去的五年里，我们收集了上百个“坏代码”的例子（其中很大一部分是我们自己写的），并且分析是什么原因使它们变坏，使用什么样的原则和技术可以让它们变好。我们发现所有的原则都源自同一个主题思想。

我们相信这是当你考虑要如何写代码时可以使用的最重要的指导原则。贯穿本书，我们会展示如何把这条原则应用于你每天编码工作的各个不同方面。但在开始之前，我们会详细地介绍这条原则并证明它为什么这么重要。

for (Node* node = list->head; node != NULL; node = node->next)

Print(node->data);

比下面的代码好：

Node* node = list->head;

if (node == NULL) return;

while (node->next != NULL) {

Print(node->data);

node = node->next;

}

if (node != NULL) Print(node->data);

（尽管两个例子的行为完全相同。）

但很多时候这个选择会更艰难。例如，这段代码：

return exponent >= 0 mantissa * (1 << exponent) : mantissa / (1 << -exponent);

它比下面这段要好些还是差些/p>

if (exponent >= 0) {

return mantissa * (1 << exponent);

} else {

return mantissa / (1 << -exponent);

}

第一个版本更紧凑，但第二个版本更直白。哪个标准更重要呢般情况下，在写代码时你如何来选择/p>

在对很多这样的例子进行研究后，我们总结出，有一种对可读性的度量比其他任何的度量都要重要。因为它是如此重要，我们把它叫做“可读性基本定理”。

关键思想：代码的写法应当使别人理解它所需的时间最小化。

这是什么意思实很直接，如果你叫一个普通的同事过来，测算一下他通读你的代码并理解它所需的时间，这个“理解代码时间”就是你要最小化的理论度量。

并且当我们说“理解”时，我们对这个词有个很高的标准。如果有人真的完全理解了你的代码，他就应该能改动它、找出缺陷并且明白它是如何与你代码的其他部分交互的。

现在，你可能会想：“谁会关心是不是有人能理解它是唯一使用这段代码的人！”就算你从事只有一个人的项目，这个目标也是值得的。那个“其他人”可能就是6个月后的你自己，那时你自己的代码看上去已经很陌生了。而且你永远也不会知道——说不定别人会加入你的项目，或者你“丢弃的代码”会在其他项目里重用。

一般来讲，你解决问题所用的代码越少就越好（参见第13章）。很可能理解2000行代码写成的类所需的时间比5000行的类要短。

但少的代码并不总是更好！很多时候，像下面这样的一行表达式：

assert((!(bucket = FindBucket(key))) || !bucket->IsOccupied());

理解起来要比两行代码花更多时间：

bucket = FindBucket(key);

if (bucket != NULL) assert(!bucket->IsOccupied());

类似地，一条注释可以让你更快地理解代码，尽管它给代码增加了长度：

// Fast version of “hash = (65599 * hash) + c”

hash = (hash << 6) + (hash << 16) – hash + c;

因此尽管减少代码行数是一个好目标，但把理解代码所需的时间最小化是一个更好的目标。

你可能在想：“那么其他约束呢是使代码更有效率，或者有好的架构，或者容易测试等些不会在有些时候与使代码容易理解这个目标冲突吗

我们发现这些其他目标根本就不会互相影响。就算是在需要高度优化代码的领域，还是有办法能让代码同时可读性更高。并且让你的代码容易理解往往会把它引向好的架构且容易测试。

本书的余下部分将讨论如何把“易读”这条原则应用在不同的场景中。但是请记住，当你犹豫不决时，可读性基本定理总是先于本书中任何其他条例或原则。而且，有些程序员对于任何没有完美地分解的代码都不自觉地想要修正它。这时很重要的是要停下来并且想一下：“这段代码容易理解吗如果容易，可能转而关注其他代码是没有问题的。

是的，要经常地想一想其他人是不是会觉得你的代码容易理解，这需要额外的时间。这样做就需要你打开大脑中从前在编码时可能没有打开的那部分功能。

但如果你接受了这个目标（像我们一样），我们可以肯定你会成为一个更好的程序员，会产生更少的缺陷，从工作中获得更多的自豪，并且编写出你周围人都爱用的代码。那么让我们开始吧！

我们的可读性之旅从我们认为“表面层次”的改进开始：选择好的名字、写好的注释以及把代码整洁地写成更好的格式。这些改变很容易应用。你可以在“原位”做这些改变而不必重构代码或者改变程序的运行方式。你还可以增量地做这些修改却不需要投入大量的时间。

这些话题很重要，因为会影响到你代码库中的每行代码。尽管每个改变可能看上去都很小，聚集在一起造成代码库巨大的改进。如果你的代码有很棒的名字、写得很好的注释，并且整洁地使用了空白符，你的代码会变得易读得多。

当然，在表面层次之下还有很多关于可读性的东西（我们会在本书的后面涵盖这些内容）。但这一部分的材料几乎不费吹灰之力就应用得如此广泛，值得我们首先讨论。

无论是命名变量、函数还是类，都可以使用很多相同的原则。我们喜欢把名字当做一条小小的注释。尽管空间不算很大，但选择一个好名字可以让它承载很多信息。

我们在程序中见到的很多名字都很模糊，例如tmp。就算是看上去合理的词，如size或者get，也都没有装入很多信息。本章会告诉你如何把信息装入名字中。

本章分成6个专题：

l  选择专业的词。

l  避免泛泛的名字（或者说要知道什么时候使用它）。

l  用具体的名字代替抽象的名字。

l  使用前缀或后缀来给名字附带更多信息。

l  决定名字的长度。

l  利用名字的格式来表达含义。

“把信息装入名字中”包括要选择非常专业的词，并且避免使用“空洞”的词。

例如，“get”这个词就非常不专业，例如在下面的例子中：

def GetPage(url): …

“get”这个词没有表达出很多信息。这个方法是从本地的缓存中得到一个页面，还是从数据库中，或者从互联 中果是从互联 中，更专业的名字可以是FetchPage()或者DownloadPage()。

下面是一个BinaryTree类的例子：

class BinaryTree

{

int Size();

…

};

你期望Size()方法返回什么呢的高度，节点数，还是树在内存中所占的空间/p>

问题是Size()没有承载很多信息。更专业的词可以是Height()、NumNodes()或者MemoryBytes()。

另外一个例子，假设你有某种Thread类：

class Thread

{