> # 可读性基本定理

---

1. 代码的写法应当使别人理解它所需的时间最小化

2. 可读性定理总是先于其他的条例或原则

3. 大开大脑中编码时需要注意可读性的呢一部分

##### 第一部分

_表面层次的改进_ 名字、注释、格式

**把信息装到名字里**

1. 选择专业的词

2. 找到鞥有表现力的词

3. 避免像tmp和retval这样泛泛的名字

4. 循环迭代器

5. 对于空泛名字的裁定

6.用具体的名字代替抽象的名字

7.为名字附带更多信息

8.带单位的值

9.附带其他重要属性

**名字应该有多长**

1. 在小的作用域里可以使用短的名字

2. 代码补全-输入长名字，不再是问题

3. 首字母缩略和缩写

4. 丢掉没用的词

**利用名字的格式来传递含义**

1. 其他格式规范 构造函数首字母大写，其他函数首字母小写

>  总结 使用专业的单词、避免空凡的名字、使用具体的名字来更细致的描述事物、给变量名带上重要的细节、为作用域大的名字采用更长的名字、有目的使用大小写，下划线等。

##### 不会误解的名字

关键思想-这个名字会被别人误解成其他的含义吗

1. 推荐用min和max来表示极限

2. 推荐用first和last来表示包含的范围

3. 推荐用begin和end来表示包含/排除范围

4. 给bool值命名

5. 与使用者的期望相匹配

6. 如何权衡多个备选名字

##### 审美

> 段落的长度、栏的宽度、文章的顺序、封面

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

2. 让相似的代码看上去相似

3. 把相关的代码行分组，形成代码块

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

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

3.在需要时使用列对齐

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

5.把声明按块组织起来

6.把代码分成“段落”

7.个人风格和一致性  一致的风格比“正确”的风格重要

##### 读写什么样的注释

关键思想 注释的目的是尽量帮助读者了解的和作者一样多

**什么不需要注释**

不要为那些从代码本身就能快速推断的事实写注释

**不要为了注释而注释**

**不要给不好的名字加注释-应当把名字改好**

**记录你的想法**

**加入“导演评论”**

**为代码中的瑕疵写注释**

**给常量加注释**

**站在读者的角度**

1. 意料之中的提问

2. 公布可能的陷阱

3. “全局观”注释

4. 总结性注释

**最后的思考---克服“作者心理阻滞”**

##### 写出言简意核的注释

关键思想--注释应当有很高的信息/空间率

1. 让注释保持紧凑

2. 避免使用不明确的代词

3. 润色粗糙的句子

4. 精确的描述函数的行为

5. 用输入/输出例子来说明特别的情况

6. 声明代码的意图

7. “具名函数参数”的注释

8. 采用信息含量高的词

##### 简化循环和逻辑

**把控制流变得易读**

关键思想--把条件、循环以及其他对控制流的改变做的越“自然越好”。运用一种方式使读者不用停下来重读你的代码

1. 条件语句中参数的顺序

2. if/else语句块的顺序

3. ？：条件表达式  最小化理解它所需的时间

4. 避免do/while循环

5. 从函数中提前返回

6. 臭名昭著的goto

7. 最小化嵌套

8. 嵌套是如何累积而成的

9. 通过提早返回来减少嵌套

10. 减少循环内的嵌套

##### 拆分超长的表达式

关键思想--把你的超长表达式拆分成更容易理解的小块

1. 用作解释的变量

2. 总结变量

3. 使用德摩根定理

4. 滥用短路逻辑

5. 找到更优雅的方式

6. 拆分巨大的语句

7. 另一个简化表达式的创意方法

##### 变量和可读性

变量的缺点

**减少变量**

1. 没有价值的临时变量

2. 减少中间结果

3. 减少控制流变量

4. 缩小变量的作用域

5. C++中if的作用域

6. 在JavaScript中创建“私有”变量

7. JavaScript全局作用域

8. 在python和JavaScript中没有嵌套的作用域

9. 把定义向下移

10. 只写一次的变量更好

##### 重新组织代码

函数级别的代码改动

1. 抽取不相关的子问题

2. 纯工具代码

3. 其他多用途代码

4. 意料之外的好处

5. 创建大量通用的代码

6. 项目专有的功能

7. 简化已有接口

8. 按需重塑接口

9. 过犹不及

##### 一次只做一件事

1. 任务可以很小

2. 从对象中抽取值

3. 更大型的例子

4. 进一步的改进成

##### 把想法变成代码

1. 清楚地描述逻辑

2. 了解函数库是有帮助的

3. 把这个方法应用于更大的问题

##### 少写代码

关键思想--最好读的代码就是没有代码

1. 别费神实现呢各功能---你不会需要他

2. 质疑和拆分你的需求

3. 保持小代码库

4. 熟悉你周边的库

5. 为什么重用库有这么大的好处

##### 精选话题

**测试与可读性**

1. 使测试易于阅读和维护

2. 这段测试什么地方不对

3. 使这个测试更可读

4. 创建最小的测试声明

5. 实现定制的“微语言”

6. 让错误信息具有可读性

7. 更高级的assert（）

8. 手工打造错误信息

9. 选择好的测试输入

10. 简化输入值

11. 一个功能的多个测试

12. 为测试函数命名

13. 那个测试有什么地方不对

14. 对测试较好的开发方式

##### 设计并改进“分钟、小时计数器”

**定义类接口**

1. 改进命名

2. 改进注释