作者:
[美] Dustin Boswell
/
[美] Trevor Foucher
出版社: 机械工业出版社
原作名: The Art of Readable Code: Simple and Practical Techniques for Writing Better Code
译者: 尹哲 / 郑秀雯
出版年: 2012-7-10
页数: 240
定价: 59.00元
装帧: 平装
丛书: O’Reilly精品图书系列
ISBN: 9787111385448
出版社: 机械工业出版社
原作名: The Art of Readable Code: Simple and Practical Techniques for Writing Better Code
译者: 尹哲 / 郑秀雯
出版年: 2012-7-10
页数: 240
定价: 59.00元
装帧: 平装
丛书: O’Reilly精品图书系列
ISBN: 9787111385448
内容简介 · · · · · ·
细节决定成败,思路清晰、言简意赅的代码让程序员一目了然;而格式凌乱、拖沓冗长的代码让程序员一头雾水。除了可以正确运行以外,优秀的代码必须具备良好的可读性,编写的代码要使其他人能在最短的时间内理解才行。本书旨在强调代码对人的友好性和可读性。
本书关注编码的细节,总结了很多提高代码可读性的小技巧,看似都微不足道,但是对于整个软件系统的开发而言,它们与宏观的架构决策、设计思想、指导原则同样重要。编码不仅仅只是一种技术,也是一门艺术,编写可读性高的代码尤其如此。如果你要成为一位优秀的程序员,要想开发出高质量的软件系统,必须从细处着手,做到内外兼修,本书将为你提供有效的指导。
编写可读代码的艺术的创作者
· · · · · ·
-
D·Boswell 作者
作者简介 · · · · · ·
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
· · · · · · (收起)
第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
· · · · · · (收起)
丛书信息
· · · · · ·
O’Reilly精品图书系列(共30册),
这套丛书还有
《云转型》《SQL与关系数据库理论:如何编写健壮的SQL代码(原书第2版)》《UNIX与Internet安全实践指南》《客户驱动的产品开发》《解密金融数据》
等
。
喜欢读"编写可读代码的艺术"的人也喜欢的电子书 · · · · · ·
支持 Web、iPhone、iPad、Android 阅读器
喜欢读"编写可读代码的艺术"的人也喜欢 · · · · · ·
编写可读代码的艺术的书评 · · · · · · ( 全部 34 条 )
注重代码质量利国利民
本书主要观点: 1. 优雅的命名 1.1 命名具备自解释性(解释用途) 1.2 能附加(必要的)更多信息(匈牙利命名法的类型信息) 1.3 命名格式统一,如 kConstName 骆驼命名法或单词下划线 bool变量的is, has, can等前缀 ... 1.4 遵循业界的命...
(展开)
确实很多是实践中的体现出来的问题
之前做重构项目的时候,就发现了代码质量的问题,一些老模块的代码写的简直令人发指,没有文档没有任何资料的情况下,只能人肉去读代码梳理功能,经历了各种痛苦,后来也不断在组内各种灌输代码质量的意识,在这方面做了一些推动。 偶然间翻了这本书,感觉一下找到了知己,命名...
(展开)
《The art of readable code》笔记
《The art of readable code》笔记 25 November 2012 前言 入职新公司,接收前任留下的code,觉得有些凌乱,于是乘势带着学习的心态又把整个代码重写了遍。期间又把去年读过的这本书拿过来重读了一遍,这本书举的例子是作者平时的一些总结,作为顶尖互联网公司(Google)的工程师...
(展开)
> 更多书评 34篇
论坛 · · · · · ·
看了 (More) Effective C++ 和 Google Style Guide... | 来自御宅暴君 | 2 回应 | 2023-01-07 11:07:54 |
The Art of Readable Code | 来自花音妙 | 2013-06-29 09:09:29 | |
《编写可读代码的艺术》“晒书有礼”活动进行中 | 来自何艳 | 2 回应 | 2013-06-09 09:56:41 |
这本书的其他版本 · · · · · · ( 全部4 )
-
O'Reilly Media (2011)8.7分 296人读过
-
东南大学出版社 (2012)9.1分 32人读过
-
オライリージャパン (2012)暂无评分 5人读过
以下书单推荐 · · · · · · ( 全部 )
- 改变自己▶编程 (Chain)
- ThoughtWorks程序员读书雷达(2013) (张凯峰)
- ThoughtWorks读书雷达(2016) (张凯峰)
- 计算机科学 (月亮)
- 程序员必读 (沨雅)
谁读这本书? · · · · · ·
二手市场
· · · · · ·
订阅关于编写可读代码的艺术的评论:
feed: rss 2.0
1 有用 やまだ 2020-04-12 13:27:09
代码也是语言,既然是语言,可理解可交流当然就很重要_(:з」∠)_
13 有用 飞林沙 2013-11-26 22:41:37
这种关于代码的书去读Clean Code和代码大全就足够了,真的没必要读一本又一本。这本书关于注释的见解还是比较深刻的,其余的就没什么太多营养了,而且很啰嗦.....
3 有用 悟怡 2012-10-03 05:31:26
很实在的编程建议小书。虽然不少都了解点,但知易行难。有追求的程序员都会如作者般注意代码品质的,我们写出来的代码是给人看的,给自己看的,所以对可读性的追求是必须的。里面的插图挺多,还多搞笑的。
2 有用 松鼠亲自奥利奥 2014-02-06 21:06:10
其实大部分内容 import this 都涵盖了~很多大实话,但是归纳总结出来了还是很有价值的。最大的收获是学会了如何起名字!
0 有用 huangz 2012-10-28 11:54:07
重读了一次,觉得这本书还是很不错的,嗯。之前给分太低了。
0 有用 cosimo 2024-02-07 17:10:21 北京
不错 年前摸鱼的下午看完了 很多细节在日常工作中已经内化了 不求代码写的优雅 只求尽量写的鲁棒 让自己好维护 虽然有时这两者是一件事
0 有用 okfine 2023-10-07 15:52:26 江苏
变量的作用域、测试代码的可读性(类似 Spock)、计数器的 C++ 实现(时间桶)
1 有用 GoXXIV 2023-08-12 22:53:44 山东
前面注释部分的讲的还不错,后面几章就记住一句话,大致意思是,每隔一段时间花十五二十分钟看下文档,为的是使用现有的api完成功能,减少重复代码也能减少错误。
0 有用 momo 2023-05-19 16:28:50 山东
写的挺全面的,适合新手阅读
0 有用 精武英雄 2023-03-21 23:17:48 四川
2023年3月21日开始阅读 今天迅速读完了。本书相当于一个coding style 规范书。适合入门级选手阅读。新手也应该读一下。 本书简单提到了代码测试,这里需要找资料深入学习一下。相信对工作会有帮助