笔记说明
这篇记录基本都是对原文的摘抄。原书写的非常通俗易懂，例子也比较贴切，读起来毫不费力。原书的目录即大纲，事实上把目录扫一遍或把每章之后的总结翻一遍，也就知道讲了哪些思想了。
因为在读的过程中感受到很多有益的思想，比如可读性定理、自然语言描述等等，我觉得应当把它们都总结起来，这样在开始coding以及review的时候可以很快地过一遍以查漏补缺。
其实最好是抽时间把原书通读一遍，很快的~ 如果没有时间，也可以把下面的总结过一下，几分钟的时间，也许会有所启发。如果有哪里有疑问，再去书中翻一下对应的章节看一下例子。
如果对这些思想有印象的话，在coding时应当可以找到正确的方法，避免一些想当然的错误写法。或者在两种写法里抉择时会有新的启发。
译者序
代码最重要的读者是人。写出的代码能让人快速理解、轻松维护、容易扩展的程序员才是专业的程序员。
第一部分 表面层次的改进
第1章 代码应当易于理解
可读性基本定理
有一种对可读性的度量比其他任何的度量都要重要。
代码的写法应当使别人理解它所需的时间最小化。
可读性基本定理总是先于本书中任何其它条例或原则。
第2章 把信息装到名字里
- 使用专业的单词（比如用 Fetch 或 Download 代替 Get）
- 避免空泛的名字（比如 tmp）
- 使用具体的名字来更细致地描述事物
- 给变量名带上重要的细节（如单位、raw_)
- 如果你的变量是一个度量的话（如时间长度或者字节数），那么最好把名字带上它的单位。
- 为作用域大的名字采用更长的名字
- 有目的地使用大小写、下划线等
第3章 不会误解的名字
不会误解的名字是最好的名字
一些tips：
- 当要定义一个值的上限或下限时，max_和min_是很好的前缀。
- 对于包含的范围，first和last是好的选择。
- 对于包含/排除范围，begin和end是最好的选择，因为它们最常用。
- 当为布尔值命名时，使用is和has这样的词来明确表示它是个布尔值，避免使用反义的词（例如disable_ssl）
- 要小心用户对特定词的期望。例如，用户会期望get()或者size()是轻量的方法。
第4章 审美
审美与好的设计是两种独立的思想
使代码“看上去漂亮”通常会带来不限于表面层次的改进，它可能会帮你把代码的结构做得更好。
一致的风格比“正确”的风格更重要。
不要给不好的名字加注释——应该把名字改好
好代码＞坏代码+好注释。
把大块代码分成逻辑上的“段落”。
第5章 该写什么样地注释
什么地方不需要注释
- 能从代码本身中迅速地推断的事实。
- 用来粉饰烂代码（例如蹩脚的函数名）的“拐杖式注释”——应该把代码改好。
读者立场思考：
- 预料到代码中哪些部分会让读者说：“啊？”并且给它们加上注释。
- 为普通读者意料之外的行为加上注释。
- 件/类的级别上使用“全局观”注释来解释所有的部分是如何一起工作的。
- 注释来总结代码块，使读者不致迷失在细节中。
第6章 写出言简意赅地注释
- 声明代码的高层次意图，而非明显的细节。
第二部分 简化逻辑和循环
第7章 把控制流变得易读
- 在写一个比较时（
while(bytes_expected ＞ bytes_received)），把改变的值写在左边并且把更稳定的值写在右边更好一些 - if/else:先处理正确的、简单的、有趣的情况
- 用线性的代码，避免深嵌套
- 提早返回可以减少嵌套并让代码整洁
第8章 拆分超长的表达式
- 引入“解释变量/总结变量”来代替较长的子表达式
- 用德摩根定理来操作逻辑表达式
第9章 变量与可读性
- 减少不能改进可读性的变量
- 比如没有价值的临时变量
- 中间结果
- 控制流变量
- 缩小变量的作用域
让你的变量对尽量少的代码行可见
- JS 可以用闭包实现这一目的
- 常量（const、final、常量） is better
第三部分 重新组织代码
三种组织代码的方法：
- 抽取出那些与程序主要目的“不相关的子问题”。
- 重新组织代码使它一次只做一件事情。
- 先用自然语言描述代码，然后用这个描述来帮助你找到更整洁的解决方案。
- 可以把代码完全移除或者一开始就避免写它的那些情况——唯一可称为改进代码可读性的最佳方法。
第10章 抽取不相关的子问题
把一般代码和项目专有的代码分开
第11章 一次只做一件事
应该把代码组织得一次只做一件事情。
流程：
- 列出代码所做的所有“任务”。这里的“任务”没有很严格的定义——它可以小得如“确保这个对象有效”，或者含糊得如“遍历树中所有结点”。
- 尽量把这件任务拆分到不同的函数中，或者至少是代码中不同的段落中。
第12章 把想法变成代码
橡皮鸭技术
- 像对着一个同事一样用自然语言描述代码要做什么。
- 注意描述中所用的关键词和短语。
- 写出与描述所匹配的代码。
第13章 少写代码
- 从项目中消除不必要的功能，不要过度设计。
- 重新考虑需求，解决版本最简单的问题，只要能完成工作就行。
- 经常性地通读标准库的整个API，保持对它们的熟悉程度。
第四部分 精选话题
第14章 测试与可读性
- 每个测试的最高一层应该越简明越好。最好每个测试的输入/输出可以用一行代码来描述。
- 如果测试失败了，它所发出的错误消息应该能让你容易跟踪并修正这个bug。
- 使用最简单的并且能够完整运用代码的测试输入。
- 给测试函数取一个有完整描述性的名字，以使每个测试所测到的东西很明确。不要用Test1()，而用像Test_FunctionName_Situation 这样的名字。
- 要使它易于改动和增加新的测试。
