第一章 代码应当易于理解

• 是什么让代码变得“更好”
• 可读性基本定理（代码的写法应当使别人理解它所属时间最小化）**
• 总是越小越好吗

第二章 把信息装到名字里

• 选择专业的词
  找到更有表现力的词（清晰和精确比装可爱好）
• 避免像tmp和retval这样泛泛的名字
  tmp（tmp这个名字只应用于短期存在且临时性为其主要存在因素的变量）
  循环迭代器
  对于空泛名字的裁定
• 用具体的名字代替抽象的名字
• 为名字附带更多信息
  带单位的值
  附带其它重要属性
• 名字应该有多长
  在小的作用域里可以使用短的名字
  输入长名字－－不再是个问题
  首字母缩略词和缩写（团队新成员是否能够理解其含义？）
  丢掉没用的词
• 利用名字的格式来传递含义
• 其他格式规范

第三章 不会误解的名字

要多问自己几遍：“这个名字会被别人解读成其他的含义吗？”要仔细审视这个名字。

• 推荐用min和max来表示（包含）极限
• 推荐用first和last来表示包含的范围
• 推荐用begin和end来表示包含／排除范围
• 给布尔值命名（加上is、has、can或should这样的词，可以把布尔值变得更明确）
• 与使用者的期望相匹配

第四章 审美

三原则：

• 使用一致的布局，让读者很快就习惯这种风格。

• 让相似的代码看上去相似。

• 把相关的代码行分组，形成代码块。

• 为什么审美这么重要

• 重新安排换行来保持一致和紧凑

• 用方法来整理不规则的东西

• 在需要的时使用列对齐（你应该使用列对齐吗？）

• 选一个有意义的顺序，始终一致地使用它

• 把声明按块组织起来

• 把代码分成“段落”

• 个人风格与一致性

第五章 该写什么样的注释

注释的目的是尽量帮助读者了解得和作者一样多。

• 什么不需要注释（不要为那些从代码本身就能快速推断事实写注释）
  不要为了注释而注释
  不要给不好的名字加注释——应该把名字改好
• 记录你的思想
  加入“导演评论“
  为代码中的瑕疵写注释
  给常量加注释
• 站在读者的角度
  意料之中的提问
  公布可能的陷阱
  ”全局观“注释
  总结性注释
• 最后的思考——克服”作者心理阻滞“
  不管你心里想什么，先把它写下来
  读一下这段注释，看看有没有什么地方可以改进
  不断改进