#第一章 代码应当易于理解
- 是什么让代码变得“更好”
- 可读性基本定理**（代码的写法应当使别人理解它所属时间最小化）**
- 总是越小越好吗
#第二章 把信息装到名字里
- 选择专业的词 找到更有表现力的词（清晰和精确比装可爱好）
- 避免像tmp和retval这样泛泛的名字 tmp（tmp这个名字只应用于短期存在且临时性为其主要存在因素的变量） 循环迭代器 对于空泛名字的裁定
- 用具体的名字代替抽象的名字
- 为名字附带更多信息 带单位的值 附带其它重要属性
- 名字应该有多长 在小的作用域里可以使用短的名字 输入长名字－－不再是个问题 首字母缩略词和缩写（团队新成员是否能够理解其含义？） 丢掉没用的词
- 利用名字的格式来传递含义
- 其他格式规范
#第三章 不会误解的名字
要多问自己几遍：“这个名字会被别人解读成其他的含义吗？”要仔细审视这个名字。
- 推荐用min和max来表示（包含）极限
- 推荐用first和last来表示包含的范围
- 推荐用begin和end来表示包含／排除范围
- 给布尔值命名（加上is、has、can或should这样的词，可以把布尔值变得更明确）
- 与使用者的期望相匹配
#第四章 审美
三原则：
-
使用一致的布局，让读者很快就习惯这种风格。
-
让相似的代码看上去相似。
-
把相关的代码行分组，形成代码块。
-
为什么审美这么重要
-
重新安排换行来保持一致和紧凑
-
用方法来整理不规则的东西
-
在需要的时使用列对齐（你应该使用列对齐吗？）
-
选一个有意义的顺序，始终一致地使用它
-
把声明按块组织起来
-
把代码分成“段落”
-
个人风格与一致性
#第五章 该写什么样的注释 >注释的目的是尽量帮助读者了解得和作者一样多。
- 什么不需要注释（不要为那些从代码本身就能快速推断事实写注释） 不要为了注释而注释 不要给不好的名字加注释——应该把名字改好
- 记录你的思想 加入“导演评论“ 为代码中的瑕疵写注释 给常量加注释
- 站在读者的角度 意料之中的提问 公布可能的陷阱 ”全局观“注释 总结性注释
- 最后的思考——克服”作者心理阻滞“ 不管你心里想什么，先把它写下来 读一下这段注释，看看有没有什么地方可以改进 不断改进
转播
