代码应当易于理解
代码的写法应当使他人理解它所需的时间最小化
把信息装进名字中
清晰和精确比装可爱好
使用专业的词
使用详细的名字来更仔细地描写叙述事物
给变量名带上重要的细节
为作用域大的名字採用更长的名字
有目的地使用大写和小写。下划线等
要多问自己几遍：“这个名字会被别人解读成其它的含义吗？” 要仔细审视这个名字，不会被误解的名字是最好的名字
命名极限最清晰的方式是在要限制的东西前加上max_或者min_
为布尔值命名时，避免使用反义的词（比如disable_ssl）
要小心用户对特定词的期望。比如，用户会期望get()或者size()是轻量的方法
审美
一致的风格比“正确”的风格更重要
假设多个代码块做类似的事情。尝试让他们有相同的剪影
把代码按“列”对齐能够让代码更easy浏览
假设在一段代码中提到A,B,C。那么不要在还有一段中说B,C,A。选择一个有意义的次序。并始终用这种顺序
用空行来把大块代码分成逻辑上的“段落”
凝视
凝视的目的是尽量帮助读者了解的和作者一样多
什么地方不须要凝视：
- 能从代码本身中迅速地判断的事实
- 用来粉饰烂代码的“拐杖式凝视”--应该把代码改好
你应当记录下来的想法包含：
- 对于为什么代码写成这样而不是那样的内在理由（“指导性批注”）
- 代码中的缺陷，使用像TODO:或者XXX:这种标记
- 常量背后的故事，为什么是这个值
站在读者的立场上思考：
- 预料到代码中哪些部分会让读者说：“啊？” 而且给他们加上凝视
- 为普通读者意料之外的行为加上凝视
- 在文件/类的级别上使用“全局观”凝视来解释全部的部分是怎样一起工作的
- 用凝视来总结代码块，使读者不至于迷失在细节中
凝视应当有非常高的信息/空间率
尽量精确地描写叙述函数的行为
在凝视中用精心挑选的输入/输出样例进行说明
声明代码的高层次意图，而非明显的细节
用含义丰富的词来使凝视简洁
控制流
把条件。循环以及其它对控制流的改变做的越“自然”越好，运用一种方式使读者不用停下来重读你的代码
相对于追求最小化代码行数，一个更好的度量方法是最小化人们理解它所需的时间
当你对代码做修改时，从全新的角度审视它。把它作为一个总体来看待
在写一个比較时，把改变的值写在左边而且把更稳定的值写在右边更好一些
你也能够又一次排列if/else语句中的语句块，通常来讲。先处理正确的/简单的/有趣的情况
尽量不要用三目运算符
嵌套的代码块须要更加集中精力去理解，应该把它们改写成更加“线性”的代码来避免深浅套
通常来讲提早返回能够降低嵌套并让代码整洁
表达式
把你的超长表达式拆分成更easy理解的小块
要小心“智能”的小代码块--它们往往在以后会让别人读起来感到困惑
引入“解释变量”来代表较长的子表达式，这种方式有三个优点：
- 它把巨大的表达式拆成小段
- 它通过用简单的名字描写叙述子表达式来让代码文档化
- 它帮助读者识别代码中的主要概念
用德摩根定理来操作逻辑表达式--能够把布尔表达式用更整洁的方式重写（比如if(!(a&&!b))变成if(!a||b)）
有时须要把问题“反向”或者考虑目标的对立面
变量与可读性
你希望你的同事随时都认为是在面试吗
让你的变量对尽量少的代码行可见
操作一个变量的地方越多。越难以确定它的当前值
降低变量，即那些妨碍的变量
减小变量的作用域。越小越好，把变量移到一个有最少代码能够看到它的地方，眼不见，心不烦
仅仅写一次的变量更好。那些仅仅设置一次值的变量（或者const, final, 常量）使得代码更easy理解
又一次组织代码
把一般代码和项目专有的代码分开
应该把代码组织得一次仅仅做一件事情
把想法变成代码，用自然语言描写叙述解决方式
最好的代码就是没有代码
删除无用的代码
从项目中消除不必要的功能，不要过度设计
又一次考虑需求，解决版本号最简单的问题。仅仅要能完毕工作即可
常常性地通读标准库的整个API，保持对他们的熟悉程度--“不要反复造轮子”
測试
測试也应当具有可读性。以便其它程序猿能够舒服地改变或者添加測试
对使用者隐去不重要的细节，以便更重要的细节会更突出
让错误消息具有可读性
又简单又能完毕工作的測试值更好
每一个測试的最高一层应该越简明越好。最好每一个測试的输入/输出能够用一行代码来描写叙述
假设測试失败了，它所发出的错误消息应该能让你easy跟踪并修正这个bug
使用最简单的而且能够完整运用代码的測试输入
给測试函数取一个有完整描写叙述性的名字，以使每一个測试所測到的东西非常明白，不要使用test1()。而要使用test_<functionName>这种名字
最重要的是。要使它易于修改和添加新的測试