编写可读代码的艺术

前言 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

......(更多)