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条件语句中参数的顺序 70if/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
评论关闭。