| 商家名称 | 信用等级 | 购买信息 | 订购本书 |
 |
 |
编写可读代码的艺术 |  |
 |
|
编写可读代码的艺术 | |
![编写可读代码的艺术 [平装]](http://img.reader8.net/uploadfile/2013/0423/20130423014350184.jpg "编写可读代码的艺术")
《编写可读代码的艺术》写出的代码能让人快速理解、轻松维护、容易扩展的程序员才是专业的程序员。《编写可读代码的艺术》简化命名、注释和格式的方法，使每行代码都言简意赅；梳理程序中的循环、逻辑和变量来减小复杂度并理清思路；编写有效的测试代码，使其全面而简洁，同时可读性更高。
"软件开发的一个重要部分是要意识到你的代码以后将如何影响查看这些代码的人。两位作者高屋建瓴，带你领略这一挑战的各个方面，并且使用有指导意义的例子来解释细节。"
——Michael Hunger，软件开发人员
作者：（美国）鲍斯维尔（Dustin Boswell） （美国）富歇（Trevor Foucher） 译者：尹哲 郑秀雯
鲍斯维尔（Dustin Boswell）毕业于加州理工大学，资深软件工程师，在Google就职多年，负责Web爬虫和程序设计相关的工作。他专注于前端、后端，服务器架构、机器学习、大数据、系统和网站等技术领域的研究和实践，经验十分丰富。他现在是MyLikes的软件工程师。
富歇（Trevor Foucher）资深软件工程师和技术经理，先后在Microsoft和Google工作了数十年，在Microsoft担任软件工程师、技术经理以及安全产品技术主管，在Google从事广告应用开发和搜索基础结构研发相关的工作。
前言 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
我们曾经在非常成功的软件公司中和出色的工程师一起工作，然而我们所遇到的代码仍有很大的改进空间。实际上，我们曾见到一些很难看的代码，你可能也见过。
但是当我们看到写得很漂亮的代码时，会很受启发。好代码会很明确告诉你它在做什么。使用它会很有趣，并且会鼓励你把自己的代码写得更好。
本书旨在帮助你把代码写得更好。当我们说“代码”时，指的就是你在编辑器里面要写的一行一行的代码。我们不会讨论项目的整体架构，或者所选择的设计模式。当然那些很重要，但我们的经验是程序员的日常工作的大部分时间都花在一些“基本”的事情上，像是给变量命名、写循环以及在函数级别解决问题。并且这其中很大的一部分是阅读和编辑已有的代码。我们希望本书对你每天的编程工作有很多帮助，并且希望你把本书推荐给你团队中的每个人。
本书内容安排
这是一本关于如何编写具有高可读性代码的书。本书的关键思想是代码应该写得容易理解。确切地说，使别人用最短的时间理解你的代码。
本书解释了这种思想，并且用不同语言的大量例子来讲解，包括C++、Python、JavaScript和Java。我们避免使用某种高级的语言特性，所以即使你不是对所有的语言都了解，也能很容易看懂。（以我们的经验，反正可读性的大部分概念都是和语言不相关的。）
每一章都会深入编程的某个方面来讨论如何使代码更容易理解。本书分成四部分：
?表面层次上的改进
命名、注释以及审美——可以用于代码库每一行的小提示。
?简化循环和逻辑
在程序中定义循环、逻辑和变量，从而使得代码更容易理解。
?重新组织你的代码
在更高层次上组织大的代码块以及在功能层次上解决问题的方法。
?精选话题
把“易于理解”的思想应用于测试以及大数据结构代码的例子。
如何阅读本书
我们希望本书读起来愉快而又轻松。我们希望大部分读者在一两周之内读完全书。
章节是按照"难度"来排序的：基本的话题在前面，更高级的话题在后面。然而，每章都是独立的。因此如果你想跳着读也可以。
代码示例的使用
本书旨在帮助你完成你的工作。一般来说，可以在程序和文档中使用本书的代码。如果你复制了代码的关键部分，那么你就需要联系我们获得许可。例如，利用本书的几段代码编写程序是不需要许可的。售卖或出版书中示例的D-ROM需要我们的许可。引用本书回答问题以及引用示例代码不需要我们的许可。将本书的大量示例代码用于你的产品文档中需要许可。
版权页：
插图：
然后，随着项目的增长，你的目录中加进了越来越多的源文件。很快你就需要多个目录来组织它们了。很难再记得哪个函数调用了哪个函数，而且跟踪bug也要做多一点的工作。
最后，你就有了很多源代码分布在很多不同的目录中。项目很大，没有一个人自己全部理解它。增加新功能变得很痛苦，而且使用这些代码很费力还令人不快。
我们所描述的是宇宙的自然法则——随着任何坐标系统的增长，把它粘合在一起所需的复杂度增长得更快。
最好的解决办法就是"让你的代码库越小，越轻量级越好"，就算你的项目在增长。那么你就要：
?创建越多越好的"工具"代码来减少重复代码（见第10章）。
?减少无用代码或没有用的功能（见下图）。
?让你的项目保持分开的子项目状态。
?总的来说，要小心代码的"重量"。让它保持又轻又灵。
园丁经常修剪植物以让它们活着并且生长。同样地，修剪掉碍事和没用的代码也是个好主意。
一旦代码写好后，程序员往往不情愿删除它，因为它代表很多实际的工作量。删掉它可能意味着承认在上面所花的时间就是浪费。不要这么想！这是一个有创造性的领域——摄影家、作者和电影制版人也不会保留他们所有的工作。
删除独立的函数很简单，但有时"无用代码"实际上交织在你的项目中，你并不知情。下面是一些例子：
?你一开始把系统设计成能处理多语言文件名，现在代码中到处都充满了转换代码。然而，那段代码不能很好地工作，实现上你的程序也从来没有用到过任何多语言文件名。
?为什么不删除这个功能呢？
?你希望你的程序在内存耗尽的情况下仍能工作，因此你有很多耍小聪明的逻辑来试着从内存耗尽的情况下恢复。这是个好主意，但在实践中，当系统内存耗尽时，你的程序将变成不稳定的僵尸——所有的核心功能都不可用，再点一下鼠标它就死了。
为什么不通过一句简单的提示"系统内存不足，抱歉"并删除所有内存不足的代码，终止程序呢？
更多软件工程图书请访问:http://www.reader8.net/book/ruanjian/
更多图书资讯可访问读书人网图书频道：http://www.reader8.net/book/
