具体描述
细节决定成败，思路清晰、言简意赅的代码让程序员一目了然；而格式凌乱、拖沓冗长的代码让程序员一头雾水。除了可以正确运行以外，优秀的代码必须具备良好的可读性，编写的代码要使其他人能在最短的时间内理解才行。本书旨在强调代码对人的友好性和可读性。
本书关注编码的细节，总结了很多提高代码可读性的小技巧，看似都微不足道，但是对于整个软件系统的开发而言，它们与宏观的架构决策、设计思想、指导原则同样重要。编码不仅仅只是一种技术，也是一门艺术，编写可读性高的代码尤其如此。如果你要成为一位优秀的程序员，要想开发出高质量的软件系统，必须从细处着手，做到内外兼修，本书将为你提供有效的指导。
主要内容：
简化命名、注释和格式的方法，使每行代码都言简意赅。
·梳理程序中的循环、逻辑和变量来减小复杂度并理清思路。
·在函数级别解决问题，例如重新组织代码块，使其一次只做一件事。
·编写有效的测试代码，使其全面而简洁，同时可读性更高。
作者简介
Dustin Boswell毕业于加州理工大学，资深软件工程师，在Google就职多年，负责Web爬虫和程序设计相关的工作。他专注于前端、后端，服务器架构、机器学习、大数据、系统和网站等技术领域的研究和实践，经验十分丰富。他现在是MyLikes的软件工程师。
Trevor Foucher资深软件工程师和技术经理，先后在Microsoft和Google工作了数十年，在Microsoft担任软件工程师、技术经理以及安全产品技术主管，在Google从事广告应用开发和搜索基础结构研发相关的工作。
目录信息
第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
· · · · · · (收起)
读后感
很短的一本小书，基本是在编译代码的时候顺便看完的，差不多花了三天的时间吧，看完的整体感受是很实用，增加了对整理代码可读性的欲望。可以说是软实力的提升吧，书里面举的例子都很实用，基本上实战都可以用到，我觉得这本书应该至少阅读两遍吧。 除了这本书以外，还可以考虑...
每次碰到一本好书，总会觉得相见恨晚，无疑《The Art of Readable Code》是编写程序之路上越早看到越好的一本书。大神Donald E. Knuth曾经说过：“Instead of imagining that our main tasks is to instruct a computer what to do, let us concentrate rather on explaining t...
每次碰到一本好书，总会觉得相见恨晚，无疑《The Art of Readable Code》是编写程序之路上越早看到越好的一本书。大神Donald E. Knuth曾经说过：“Instead of imagining that our main tasks is to instruct a computer what to do, let us concentrate rather on explaining t...
细节决定成败，思路清晰、言简意赅的代码让程序员一目了然；而格式凌乱、拖沓冗长的代码让程序员一头雾水。除了可以正确运行以外，优秀的代码必须具备良好的可读性，编写的代码要使其他人能在最短的时间内理解才行。本书旨在强调代码对人的友好性和可读性。 本书关注编码的细节...
用户评价
读完这本书，我感觉自己像是被“点醒”了一样。我一直认为自己写代码够“工程化”了，注重效率和性能，但这本书让我看到了代码更深层的价值——沟通和协作。 书中关于“代码的沟通成本”的分析，让我深感触动。很多时候，我们花费大量时间去写代码，却忽略了维护和理解代码的时间成本。一个难以阅读的代码，就像一座难以进入的迷宫，会让团队成员望而却步，从而拖慢整个项目的进度。这本书教会我如何通过清晰的结构、一致的风格和富有意义的命名，来降低这种沟通成本。我开始更频繁地进行代码审查，并主动寻求他人的反馈，以确保我的代码能够被清晰地理解。这种改变不仅仅影响了我个人，也开始在我的团队中产生积极的影响，大家似乎都更愿意去阅读和贡献那些清晰易懂的代码了。
这本书的叙述方式非常独特，它没有生硬地灌输理论，而是通过一个个精彩的故事和案例，娓娓道来。我感觉自己像是在听一位经验丰富的工匠在分享他的心得，而不是在上一堂枯燥的技术课。 我尤其印象深刻的是关于“代码的幽灵”的章节。它描述了那些因为难以理解而遗留下来的“技术债务”，就像是代码中的幽灵，不断地困扰着后来的开发者。这本书让我深刻地意识到，编写可读代码不仅仅是为了方便别人，更是为了让自己未来的工作更轻松。当我回顾自己写的代码时，我不再会因为看不懂而感到沮丧，反而能够迅速地定位问题，进行修改和优化。这种“自我赋能”的感觉非常棒，也让我对编写高质量代码有了更强的信心和动力。
这本书真的给了我全新的视角，让我开始认真思考“可读性”这个概念。我一直以来都觉得自己写代码已经够清晰了，变量名也很直观，注释也尽量写全，但读完这本书，我才意识到自己之前是多么的“自以为是”。它没有直接教你“怎么写代码”，而是通过大量鲜活的案例，揭示了那些隐藏在优秀代码背后的原则和思维方式。 比如，书中关于“意图”的阐述，让我茅塞顿开。我以前总觉得只要功能实现了，逻辑通了就行，却忽略了代码首先是要给“人”看的。一个好的程序员，不仅仅是代码的实现者，更是代码意图的传递者。这本书让我明白，每一个变量名、每一个函数名、每一个代码块，都应该清晰地表达其存在的目的和作用。我开始尝试用更具描述性的名字，拆分过长的函数，甚至重新组织代码结构，以便让其他开发者（或者未来的自己）能够快速理解代码在做什么。这种思考过程本身就非常有价值，它迫使我去审视自己的设计思路，而不是仅仅停留在代码层面。
老实说，我拿到这本书的时候，并没有抱太大的期望，以为它会是那种讲一些陈词滥调的“最佳实践”之类的。但事实证明我错了，这本书的深刻之处在于它并没有给出“标准答案”，而是提供了一套思考框架。它不是教你“照做”，而是教你“如何思考”。 我特别喜欢书中对“隐喻”的探讨。很多时候，我们为了追求“简短”或者“高效”，会使用一些简写或者过于抽象的命名，这反而增加了理解成本。这本书用了很多生动的例子，说明如何利用现实世界的隐喻来命名，以及如何通过代码的结构来模仿我们熟悉的模式，从而降低学习曲线。这让我意识到，写代码不仅仅是技术活，更是一门艺术，需要创意思维和同理心。我开始在我的项目中尝试一些新的命名方式和组织结构，虽然需要一些时间去适应，但效果确实让我惊喜。代码不再是冰冷的指令，而更像是一个有生命力的故事，等待被阅读。
这本书带给我的不仅仅是技术上的提升，更是一种思维模式的转变。我以前总是把注意力放在“如何写出能运行的代码”，而现在，我更关注“如何写出别人能够理解和维护的代码”。 书中关于“简洁即美”的理念，让我对代码的“瘦身”有了新的认识。我之前总认为，能够实现功能就行，即使代码有些冗余。但这本书通过大量的例子，展示了如何通过重构、抽象和移除不必要的复杂性，让代码变得更加优雅和简洁。我开始尝试将冗长的代码块进行提炼，用更精炼的表达方式来实现相同的逻辑。这种过程让我感觉就像是在雕琢一件艺术品，不断地去除杂质，展现出其内在的美。现在，当我看到自己写的简洁而富有逻辑的代码时，内心的成就感是难以言喻的。
插图幽默合理，问题直指要害，方法简单易行。coding了快三年，从重构和tdd学的好方法慢慢遗忘，也由于懒惰写了很多烂代码，都被这本书当作了反例。这种书需要多读，不断反思自己在写代码时的问题。打算入手一本，推荐一下 感谢 @yangwm 图书馆。
很实在的编程建议小书。虽然不少都了解点，但知易行难。有追求的程序员都会如作者般注意代码品质的，我们写出来的代码是给人看的，给自己看的，所以对可读性的追求是必须的。里面的插图挺多，还多搞笑的。
其实大部分内容 import this 都涵盖了～很多大实话，但是归纳总结出来了还是很有价值的。最大的收获是学会了如何起名字！
翻译欠缺了点，内容非常好。
重读的时候，只需关注每一章最后的总结部分。
