第一部分 表面层次的改进
可读性代码的改进从 表面层次 的改进开始：选择好的名字、写好的注释、代码整洁的写成更好的格式。
第二章——把信息装到名字里
无论是命名变量、函数还是类，都有很多相同的原则，尝试把名字当成一个小小的注释语句，选择一个好的名字，让其承载更多的信息。
-
选择专业的词
假设你有个Thread类：
class Thread{ void Stop(); };Stop其实还可以，但是如果该线程不能恢复，使用Kill应该更好一些
-
找更有表现力的词
下面列出一些表现力更强的单词，依语境采用：
send -> deliver 、 dispatch 、 announce 、 distribute 、 route find -> search 、 extract 、 locate 、 recover start -> lanch 、 create 、 begin 、 open make -> create 、 set up 、 build 、 generate 、 compose 、 add 、 new -
用具体的名字代替抽象的名字
在给变量，函数或者其他元素命名时，要把它描述的更具体而不是更抽象。
-
为名字附带更多信息
一个变量名就像是一个小小的注释，有时候我们可以让它更有帮助些
附带其他的重要属性
-
名字应该有多长
- 在小的作用域里可以使用短的名字
- 首字母缩略词和缩写: doc = document
- 丢掉没用的词
- 利用名字的格式来传递含义
第三章——不会误解的名字
- 推荐使用 min 和 max 来表示（包含）极限
- 推荐使用 first 和 last 来表示包含的范围
- 推荐使用 begin 和 end 来表示包含/排除范围
第四章——审美
- 原则：
- 使用一致的布局，让读者很快就习惯这种风格
- 让相似的代码看上去相似
- 把相关的代码行分组，形成代码块
第五章——该写怎样的注释
- 什么地方不需要这注释
- 应该记录下来一些想法：为什么代码写成这样而不是那样、TODO、常量为什么是这个值
- 站在读者的角度去思考：
- 预料到那部分的代码会让人搞不清楚，加上注释
- 为读者意料之外的行加上注释
- 在文件/类的级别使用“全局观”注释来解释所有的部分如何一起工作的
第六章——写出言简意赅的注释
- 避免使用不明确的代词
- 尽量精确描述函数的行为
- 精心挑选输入/输出的例子
- 声明代码的高层次意图，而非明显的细节
- 用嵌入注释解释难以理解的函数参数
- 用含义丰富的词语
第二部分——简化循环和逻辑
第七章——把控制流变得易读
- 条件语句中参数的顺序：左侧的值倾向于不断变化、右侧的值更倾向于常量
- if/else 语句块的顺序：首先处理正逻辑而不是负逻辑、先处理简单的情况
- ?: 表达式：只有在简单的情况下使用
- 避免 do/while 循环
- 最小化嵌套
- 从函数中提前返回
第八章——拆分超长表达式
-
if line.split(':')[0].strip() == "root"改为username = line.split(':')[0].strip();if username == "root" - 拆分巨大的语句
第九章——变量与可读性
变量越多，就越难全部跟踪他们的动向
变量的作用越到，就需要跟踪它的动向越久
变量改变的越频繁，就越难以跟踪它的当前值
- 减少变量，即那些妨碍的变量。通过离开处理结果来消除“中间结果”变量。
- 减少每个变量的作用域，越小越好。
- 只写一次的变量更好，那些只设置一次值的变量（或者 const 、final 、常量）使得代码更容易理解。
第三部分——重新组织代码
第十章——抽取不相关的子问题
第十一章——一次只做一件事
应该把代码组织得一次只做一件事情。
第十二章——把想法变成代码
学会用自然语言描述你要实现的功能，写出和描述匹配的代码。
第十三章——少写代码
- 从项目中消除不必要的功能，不要过度设计
- 重新考虑需求，解决版本最简单的问题
- 经常性地通读标准库的整个API，保持对它们的熟悉程度
第四部分——精选话题
第十四章——测试与可读性
- 使测试易于阅读和维护
- 让错误消息更具可读性
- 选择好的测试输入
- 简化输入值
- 为测试函数命名
