本书旨在帮助你把代码写得更好，即如何写出具有高可读性的代码。每一章都会深入到编程的一个不同的方面来讨论如何让它“更容易理解”。本书的关键思想是代码应该写得容易理解，最小化别人理解你的代码所花的时间。本书围着这个中心思想，并且用大量的不同语言的例子来讲解具体操作。本书适合各个阶层的程序员和软件开发人员阅读。

编写可读代码的艺术
　　“软件开发的一个重要部分是要意识到你的代码以后将如何影响查看这些代码的人。两位作者高屋建瓴，带你领略这一挑战的各个方面，并且使用有指导意义的例子来解释细节。”
　　——Michael Hunger，软件开发人员
　　细节决定成败，思路清晰、言简意赅的代码让程序员一目了然；而格式凌乱、拖沓冗长的代码让程序员一头雾水。除了可以正确运行以外，优秀的代码必须具备良好的可读性，编写的代码要使其他人能在最短的时间内理解才行。本书旨在强调代码对人的友好性和可读性。
　　本书关注编码的细节，总结了很多提高代码可读性的小技巧，看似都微不足道，但是对于整个软件系统的开发而言，它们与宏观的架构决策、设计思想、指导原则同样重要。编码不仅仅只是一种技术，也是一门艺术，编写可读性高的代码尤其如此。如果你要成为一位优秀的程序员，要想开发出高质量的软件系统，必须从细处着手，做到内外兼修，本书将为你提供有效的指导。
　　主要内容：
　　■ 简化命名、注释和格式的方法，使每行代码都言简意赅。
　　■ 梳理程序中的循环、逻辑和变量来减小复杂度并理清思路。
　　■ 在函数级别解决问题，例如重新组织代码块，使其一次只做一件事。
　　■ 编写有效的测试代码，使其全面而简洁，同时可读性更高。

　　Dustin Boswell毕业于加州理工大学，资深软件工程师，在Google就职多年，负责Web爬虫和程序设计相关的工作。他专注于前端、后端，服务器架构、机器学习、大数据、系统和网站等技术领域的研究和实践，经验十分丰富。他现在是MyLikes的软件工程师。
　　Trevor Foucher资深软件工程师和技术经理，先后在Microsoft和Google工作了数十年，在Microsoft担任软件工程师、技术经理以及安全产品技术主管，在Google从事广告应用开发和搜索基础结构研发相关的工作。

我们曾经在非常成功的软件公司中和出色的工程师一起工作，然而我们所遇到的代码仍有很大的改进空间。实际上，我们曾见到一些很难看的代码，你可能也见过。
但是当我们看到写得很漂亮的代码时，会很受启发。好代码会很明确告诉你它在做什么。使用它会很有趣，并且会鼓励你把自己的代码写得更好。
本书旨在帮助你把代码写得更好。当我们说“代码”时，指的就是你在编辑器里面要写的一行一行的代码。我们不会讨论项目的整体架构，或者所选择的设计模式。当然那些很重要，但我们的经验是程序员的日常工作的大部分时间都花在一些“基本”的事情上，像是给变量命名、写循环以及在函数级别解决问题。并且这其中很大的一部分是阅读和编辑已有的代码。我们希望本书对你每天的编程工作有很多帮助，并且希望你把本书推荐给你团队中的每个人。
本书内容安排
这是一本关于如何编写具有高可读性代码的书。本书的关键思想是代码应该写得容易理解。确切地说，使别人用最短的时间理解你的代码。
本书解释了这种思想，并且用不同语言的大量例子来讲解，包括C++、Python、JavaScript和Java。我们避免使用某种高级的语言特性，所以即使你不是对所有的语言都了解，也能很容易看懂。（以我们的经验，反正可读性的大部分概念都是和语言不相关的。）
每一章都会深入编程的某个方面来讨论如何使代码更容易理解。本书分成四部分：
表面层次上的改进
命名、注释以及审美——可以用于代码库每一行的小提示。
简化循环和逻辑
在程序中定义循环、逻辑和变量，从而使得代码更容易理解。
重新组织你的代码
在更高层次上组织大的代码块以及在功能层次上解决问题的方法。
精选话题
把"易于理解"的思想应用于测试以及大数据结构代码的例子。
如何阅读本书
我们希望本书读起来愉快而又轻松。我们希望大部分读者在一两周之内读完全书。
章节是按照"难度"来排序的：基本的话题在前面，更高级的话题在后面。然而，每章都是独立的。因此如果你想跳着读也可以。
代码示例的使用
本书旨在帮助你完成你的工作。一般来说，可以在程序和文档中使用本书的代码。如果你复制了代码的关键部分，那么你就需要联系我们获得许可。例如，利用本书的几段代码编写程序是不需要许可的。售卖或出版O扲eilly书中示例的D-ROM需要我们的许可。引用本书回答问题以及引用示例代码不需要我们的许可。将本书的大量示例代码用于你的产品文档中需要许可。
如果你在参考文献中提到我们，我们会非常感激，但并不强求。参考文献通常包括标题、作者、出版社和ISBN。例如：“《The Art of Readable Code》by Dustin Boswell, and Trevor Foucher.2012 Dustin Boswell, and Trevor Foucher，978-0-596-80229-5。”
如果你认为对代码示例的使用已经超出以上的许可范围， 我们很欢迎你通过permissions@oreilly.com联系我们。
联系我们
有关本书的任何建议和疑问，可以通过下列方式与我们取得联系：
美国：
O扲eilly Media, Inc.
1005 Gravenstein Highway North
Sebastopol, CA 95472
中国：
北京市西城区西直门南大街2号成铭大厦C座807室（100035）
奥莱利技术咨询（北京）有限公司
我们会在本书的网页中列出勘误表、示例和其他信息。可以通过http://oreilly.com/product/9780596802301.do访问该页面。
要评论或询问本书的技术问题，请发送邮件到：
bookquestions@oreilly.com
有关我们的书籍、会议、资源中心以及O扲eilly网络，可以访问我们的网站：
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。
感谢O'Reilly团队无限的耐心和支持，他们是Mary Treseler（编辑）、Teresa Elsey（产品编辑）、Nancy Kotary（文字编辑）、Rob Romano（插图画家）、Jessica Hosman（工具）以及Abby Fox（工具）。还有我们的漫画家Dave Allred，他把我们疯狂的卡通想法展现了出来。
最后，我们想感谢Melissa和Suzanne，他们一直鼓励我们，并给我们创建条件来滔滔不绝地谈论编程话题。

计算机\程序设计

作为程序员，我们都见过那种格式凌乱、错误百出的代码。在过去的五年里，作者Dustin Boswell和Trevor Foucher分析了大量“烂代码”示例（很大一部分是作者自己的），以此判断为什么它们这么烂以及如何才能改进它们。他们的结论就是：你编写的代码要使其他人能在最短的时间内理解才行——就算这里所指代的其他人是你自己也一样。
本书重点讲述在写代码时每次都可以应用的基本原则与实践技术。使用易于理解的多语种代码例子，每一章都深入探讨如何编写可读性代码的不同方面，并且演示如何使代码更容易理解。
● 使用对每行代码都适用的小提示来简化命名、注释和格式
● 梳理程序中的循环、逻辑和变量来减小复杂度并理清思路
● 在函数级别解决问题，例如重新组织代码块让它们一次只做一件事
● 编写有效的测试代码，让它们全面而简洁——同时可读性更高
“软件开发的一个重要的部分是要意识到你的代码以后将如何影响查看这些代码的人。两位作者高屋建瓴，带你领略这一挑战的各个方面，并且使用有指导意义的例子来解释细节。”

——Michael Hunger，软件开发人员，Neo Technology

（美）Dustin Boswell，Trevor Foucher　著：Dustin Boswell毕业于加州理工学院得，并且在Google从事了5年Web爬虫基础结构和程序设计方面的工作。他创建了几个网站并且热爱从事大数据和机器学习方面的工作。 Trevor Foucher在Microsoft担任了数十年工程师、经理，以及Windows和安全产品方面的技术主管，并且在Google从事ad程序和搜索基础结构方面的工作。

尹哲 郑秀雯 译：暂无简介

在做IT的公司里，尤其是软件开发部门，一般不会要求工程师衣着正式。在我工作过的一些环境相对宽松的公司里，很多程序员的衣着连得体都算不上（搞笑的T恤、短裤、拖鞋或者干脆不穿鞋）。我想，我本人也在这个行列里面。虽然我现在改行做软件开发方面的咨询工作，但还是改不了这副德性。衣着体面的其中一个积极方面是它体现了对周围人的尊重，以及对所从事工作的尊重。比如，那些研究市场的人要表现出对客户的尊重。而大多数程序员基本上每天主要的工作就是和其他程序员打交道。那么这说明程序员之间就不用互相尊重吗？而且也不用尊重自己的工作吗？
　　程序员之间的互相尊重体现在他所写的代码中。他们对工作的尊重也体现在那里。
　　在《Clean Code》一书中Bob大叔认为在代码阅读过程中人们说脏话的频率是衡量代码质量的唯一标准。这也是同样的道理。
　　这样，代码最重要的读者就不再是编译器、解释器或者电脑了，而是人。写出的代码能让人快速理解、轻松维护、容易扩展的程序员才是专业的程序员。
　　当然，为了达到这些目的，仅有编写程序的礼节是不够的，还需要很多相关的知识。这些知识既不属于编程技巧，也不属于算法设计，并且和单元测试或者测试驱动开发这些话题也相对独立。这些知识往往只能在公司无人问津的编程规范中才有所提及。这是我所见的仅把代码可读性作为主题的一本书，而且这本书写得很有趣！
　　既然是“艺术”，难免会有观点上的多样性。译者本身作为程序员观点更加“极端”一些。然而两位作者见多识广，轻易不会给出极端的建议，如“函数必须要小于10行”或者“注释不可以用于解释代码在做什么而只能解释为什么这样做”等语句很少出现在本书中。相反，作者给出目标以及判断的标准。
　　翻译书是件费时费力的事情，好在本书恰好涉及我感兴趣的话题。但翻译本书有一点点自相矛盾的地方，因为书中相当的篇幅是在讲如何写出易读的英语。当然这里的“英语”大多数的时候只是指“自然语言”，对于中文同样适用。但鉴于大多数编程语言都是基于英语的（至少到目前为止），而且要求很多程序员用英语来注释，在这种情况下努力学好英语也是必要的。
　　感谢机械工业出版社的各位编辑帮助我接触和完成这本书的翻译。这本译作基本上可以说是在高铁和飞机上完成的（我此时正在新加坡飞往香港的飞机上）。因此家庭的支持是非常重要的。尤其是我的妻子郑秀雯（是的，新加坡的海关人员也对她的名字感兴趣），她是全书的审校者。还有我“上有的老人”和“下有的小孩”，他们给予我帮助和关怀以及不断前进的动力。
尹哲

前言 1
第1章 代码应当易于理解 5
是什么让代码变得“更好” 6
可读性基本定理 7
总是越小越好吗 7
理解代码所需的时间是否与其他目标有冲突 8
最难的部分 8
第一部分 表面层次的改进 9
第2章 把信息装到名字里 11
选择专业的词 12
避免像tmp和retval这样泛泛的名字 14
用具体的名字代替抽象的名字 17
为名字附带更多信息 19
名字应该有多长 22
利用名字的格式来传递含义 24
总结 25
第3章 不会误解的名字 27
例子：Filter() 28
例子：Clip(text, length) 28
推荐用first和last来表示包含的范围 29
推荐用begin和end来表示包含/排除范围 30
给布尔值命名 30
与使用者的期望相匹配 31
例子：如何权衡多个备选名字 33
总结 34
第4章 审美 36
为什么审美这么重要 37
重新安排换行来保持一致和紧凑 38
用方法来整理不规则的东西 40
在需要时使用列对齐 41
选一个有意义的顺序，始终一致地使用它 42
把声明按块组织起来 43
把代码分成“段落” 44
个人风格与一致性 45
总结 46
第5章 该写什么样的注释 47
什么不需要注释 49
记录你的思想 52
站在读者的角度 54
最后的思考——克服“作者心理阻滞” 58
总结 59
第6章 写出言简意赅的注释 60
让注释保持紧凑 61
避免使用不明确的代词 61
润色粗糙的句子 62
精确地描述函数的行为 62
用输入/输出例子来说明特别的情况 63
声明代码的意图 64
“具名函数参数”的注释 64
采用信息含量高的词 65
总结 66
第二部分 简化循环和逻辑 67
第7章 把控制流变得易读 69
条件语句中参数的顺序 70
if/else语句块的顺序 71
:条件表达式（又名“三目运算符”） 73
避免do/while循环 74
从函数中提前返回 76
臭名昭著的goto 76
最小化嵌套 77
你能理解执行的流程吗 80
总结 81
第8章 拆分超长的表达式 82
用做解释的变量 83
总结变量 83
使用德摩根定理 84
滥用短路逻辑 84
例子：与复杂的逻辑战斗 85
拆分巨大的语句 87
另一个简化表达式的创意方法 88
总结 89
第9章 变量与可读性 91
减少变量 92
缩小变量的作用域 94
只写一次的变量更好 100
最后的例子 101
总结 103
第三部分 重新组织代码 105
第10章 抽取不相关的子问题 107
介绍性的例子：findClosestLocation() 108
纯工具代码 109
其他多用途代码 110
创建大量通用代码 112
项目专有的功能 112
简化已有接口 113
按需重塑接口 114
过犹不及 115
总结 116
第11章 一次只做一件事 117
任务可以很小 119
从对象中抽取值 120
更大型的例子 124
总结 126
第12章 把想法变成代码 127
清楚地描述逻辑 128
了解函数库是有帮助的 129
把这个方法应用于更大的问题 130
总结 133
第13章 少写代码 135
别费神实现那个功能——你不会需要它 136
质疑和拆分你的需求 136
保持小代码库 138
熟悉你周边的库 139
例子：使用Unix工具而非编写代码 140
总结 141
第四部分 精选话题 143
第14章 测试与可读性 145
使测试易于阅读和维护 146
这段测试什么地方不对 146
使这个测试更可读 147
让错误消息具有可读性 150
选择好的测试输入 152
为测试函数命名 154
那个测试有什么地方不对 155
对测试较好的开发方式 156
走得太远 158
总结 158
第15章 设计并改进“分钟/小时计数器” 160
问题 161
定义类接口 161
尝试1：一个幼稚的方案 164
尝试2：传送带设计方案 166
尝试3：时间桶设计方案 169
比较三种方案 173
总结 174
附录 深入阅读 175