编写可读代码的艺术 表面层次上的改进 命名、注释以及审美——可以用于代码库每一行的小提示。 简化循环和逻辑 在程序中定义循环、逻辑和变量，从而使得代码更容易理解。 重新组织你的代码 在更高层次上组织大的代码块以及在功能层次上解决问题的方法。 精选话题 把"易于理解"的思想应用于测试以及大数据结构代码的例子。
第1章：代码应当易于理解1.代码应当易于理解。2.代码的写法应当使别人理解它所需的时间最小化。第一部分：表面层次的改进第2章：把信息装到名字里
1.使用专业的单词。
2.避免空泛的名字。
3.使用具体的名字来更细致地描述事物。
4.给变量名带上重要的细节。
5.为作用域大的名字采用更长的名字。
6.有目的地使用大小写、下划线等。例如，在类成员变量后面加上“_”来区分局部变量。
第3章：不会误解的名字1.要多问自己几遍：“这个名字会被别人解读成其他的含义吗？”要仔细审视这个名字。2.命名极限最清楚的方式是要在限制的东西前面加上max_或者min_。3.当为布尔值命名时，使用is和has这样的词来明确表示它是个布尔值。4.要小心用户对特定词的期望。例如，用户期望get( )或者size( )是轻量的方法。第4章：审美1.使用一致的布局，让读者很快就习惯这种风格。2.让相似的代码看上去相似。3.把相关的代码行分组，形成代码块。第5章：该写什么样的注释1.注释的目的是尽量帮助读者了解得和作者一样多。2.什么地方不需要注释：能从代码本身中迅速地推断的事实。用来粉饰烂代码的“拐杖式注释”——应该把代码改好。3.你应该记录下来的想法包括：4.站在读者的立场上思考：第6章：写出言简意赅的注释
1.注释应当有很高的信息/空间率。
2.尽量精确地描述函数的行为。
3.在注释中用精心挑选的输入/输出例子进行说明。
4.声明代码的高层次意图，而非明显的细节。
5.用嵌入的注释（如Function(/*arg =*/…)）来解释难以理解的函数参数。
6.用含义丰富的词来使注释简洁。
第二部分：简化循环和逻辑第7章：把控制流变得易读
1.把条件、循环以及其他队控制流的改变做得越“自然”越好。运用一种方式使读者不用停下来重读你的代码。
2.相对于追求最小化代码行数，一个更好的度量方法是最小化人们理解它所需的时间。
3.当你对代码做改动时，从全新的角度审视它，把它作为一个整体来看待。
4.嵌套的代码块需更加集中精力去理解。
第8章：拆分超长的表达式1.把你的超长表达式拆分成更容易理解的小块。2.要小心“智能”的小代码段——它们往往在以后会让别人读起来感到困惑。3.帮助读者识别代码中的主要概念。第9章：变量与可读性1.减少变量，即那些妨碍的变量。2.减小每个变量的作用域，越小越好。3.只写一次的变量更好。（const、final、常量）使得代码更容易理解。
第三部分：重新组织代码
第10章：抽取不相关的子问题
1.看看某个函数或代码块，问问自己：这段代码高层次的目标是什么？
2.对于每一行代码，问一下：它是直接为了目标而工作吗？
3.如果足够的行数在解决不相关的子问题，抽取代码到独立的函数中。
把一般代码和专有代码分开：它使程序员关注小而定义良好的问题，这些问题已经同项目的其他部分脱离。
第11章：一次只做一件事1.列出代码所做的所有“任务”。2.尽量把这件任务拆分到不同的函数中，或者至少是代码中不同的段落中。第12章：把想法变成代码如果你不能把一件事解释给你祖母听的话，说明你还没有真正理解它。——阿尔伯特·爱因斯坦编写更清晰的代码：1.像对着一个同事一样用自然语言描述代码要做什么。2.注意描述中所用的关键词和短语。3.写出与描述所匹配的代码。第13章：少写代码1.从项目中消除不必要的功能，不要过度设计。2.重新考虑需求，解决版本最简单的问题，只要能完成工作就行。3.经常性地通读标准库的整个API，保持对它们的熟悉程度。
第四部分：精选话题
第14章：测试与可读性
1.每个测试的最高一层应该越简明越好。最好每个测试的输入/输出可以用一行代码来描述。
2.如果测试失败了，它所发出的错误消息应该能让你容易跟踪并修正这个bug。
3.使用最简单的并且能够完整运用代码的测试输入。
4.给测试函数一个有完整描述性地名字，以使每个测试所测到的东西很明确。例如：Test_<FunctionName>_<Situation>这样的名字。
表1：可测试性差的代码特征，以及它所带来的设计问题
特征可测试性的问题设计问题
使用全局变量对于每个测试都要重置所有的全局变量（否则，不同的测试之间会互相影响）很难理解哪些函数有什么副作用。没办法独立考虑每个函数，，要考虑整个程序才能理解是不是所有的代码都能工作
一个人目睹沿途的风景，拿着相机，拍下沿途上的风景，
