编写可读代码的艺术

先放大佬的视频教学地址：https://github.com/biezhi/write-readable-code

本书宗旨：编写简单优雅的代码

引言

代码应该易于理解

1. 可读性基本定理。

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

2. 减少代码行数是可读性之后的目标。

3. 可读性与其他目标并不会冲突。

1.表面层次的改进

1.1 将信息装到名字里

• 选择专业的词
  • 找到富有表现力的词
  • 清晰、精确
• 避免泛泛的名字
  • 类似于temp这样的名字只适用于作用域很小的代码结构
  • 迭代时，做到单个元素的首字母和被迭代变量一致
• 用具体的名字代替抽象的名字
• 使用前后缀来附带更多信息
  • 如果一个变量是度量的话，最好带上它的单位
  • 将变量的关键属性体现在它的命名上
• 决定名字的长度
  • 在小的作用域里使用短的名字
  • 如果一个变量有较大的作用域，那么它的名字应该包含更多的信息
  • 首字母缩写的原则：团队的新成员是否能理解这个名字的含义
• 利用名字的格式来表达含义
  • 对于不同的实体使用不同的命名格式
  • 例如：类成员变量使用"_"做后缀来区分
  • 例如：用下划线来分开ID中的单词，用连线来区分class里的单词

1.2 不会误解的名字

避免二义性的名字的出现，不会让人误解的名字是最好的名字

• 推荐使用min_和max_表示（包含）极限
• 推荐使用first_和last_表示包含的范围
• 推荐使用begin_和end_表示包含/排除范围
• 在布尔值上面加上is,has,can或should能够变得更准确

1.3 审美

• 三个原则

  1. 使用一致的布局，让读者很快就习惯这种风格。
  2. 让相似的代码看上去相似。
  3. 把相关的代码分组，形成代码块

• 重新安排换行来保持一致和紧凑（保持对齐）
• 用新写方法来整理不规则的内容
• 必要时使用列对齐
• 选择一个有意义的顺序并始终如一地使用它
  • 让变量的顺序和html中的顺序一致
  • 从“最重要”到“最不重要”
  • 按字母排序
• 把代码分成“段落”
  • 它将相似的代码区分开来
  • 提供了可见的脚印
  • 便段落之间的导航
• 一致的风格比“正确”的风格更重要

1.5 注释

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

• 什么不需要注释
  • 不要为那些能从代码上快速推断的信息而写注释。
  • 不要给不好的名字写注释，而应该直接修改名字
• 什么需要注释
  • 很多好的注释仅通过“记录你的想法”就能得到
  • 用来解释为什么代码写得不那么整洁
  • 为代码中的瑕疵写注释
    • TODO：未完成的事
    • FIXME：已知的无法运行的代码
    • HACK：对一个问题不得不采用的粗糙解决方案
    • XXX：危险！这里有重要的问题
• 如何写注释
  • 随时把代码如何改动的想法用注释记录下来
    1. 不管怎么想，先写下来
    2. 阅读这段代码，看是不是可以改进
    3. 不断地改进，在读者可能看不懂的地方写注释
  • 给常量加注释
  • 站在读者的角度写注释
  • 公布可能的陷阱
    • 例如：多久超时
    • 例如：什么情况下会加重运行时间
  • 添加“全局观”注释，主要应对于工具类、底层代码
  • 包含“做什么”，“怎么做”，“为什么”这三方面

1.5 言简意赅的注释

注释应该有相当高的（信息/空间）率

• 让注释保持紧凑
• 避免使用不明确的代词
• 润色语言，这样同时能使注释简洁
• 精确描述函数的行为
• 用输入/输出描述特别案例
• 描述代码的意图（联系业务逻辑）
• 注释函数参数

2.简化逻辑和循环

2.1把控制流变得更可读

条件判断、循环等会让代码混乱

1. 条件语句中参数的顺序
   • 比较的左侧的值倾向于不断不变化
   • 比较的右侧倾向于固定值
2. if/else语句块的顺序
   • 优先处理正逻辑
   • 先处理简单逻辑，这样可以保持所有逻辑在一个屏幕可见
   • 先处理可疑或者有趣的部分
3. 三目运算
   • 只对于简单的情况下适合
   • 复杂情况下推荐使用if/else
   • 对于追求最小代码行数的准则：最小化人们理解它的时间
4. 避免使用do/while循环
5. 从函数中提前返回
6. 最小化嵌套
   • 通过从函数提前返回来减少嵌套
   • 减少循环内的嵌套（continue）

2.2 拆分超长的表达式

• 新增一个额外的变量来表达一个小一点的表达式
• 将一个表达式用更清晰的变量名来表示（便于理解业务逻辑的变量名）

2.3 可读性和变量

1.变量越多，越难完全判断所有变量的动向

2.变量作用域越大，追踪他们的动向话费时间越久

3.变量改变得越频繁就越难判断它的当前值

---

1. 减少不能改进可读性的变量
   • 没有价值的临时变量
   • 减少中间结果
   • 减少控制流变量
2. 缩小变量的作用域（让你的变量对尽量少的代码可见；把大的类拆分成小的类）
   • 在js中使用闭包函数
   • 在js中如果声明时未使用var关键字，则这个变量将在全局作用域中
   • 将定义靠近在第一次使用它的地方
3. 只写一次变量

小结

1. 如何找到更优雅的方式？
   • 看这种技术能否从反方向解决问题
2. 可以在任何见到复杂逻辑的地方大胆去拆分它。

3.重构代码

3.1 抽取与程序问题不相关的子问题

1. 确定代码的最高层次目标
2. 审视代码，是否为最高层次目标服务
3. 如果有足够多的行数在解决不相关的子问题，那么将代码放到独立函数中

把一般代码和项目专用代码区分

3.2 重构，使代码一次只做一件事

• 不同任务的代码可以独立成函数
• 或者成为独立的段落

3.3 先用自然语言描述，再用代码去实现（橡皮鸭技术）

用自然语言解释清楚的问题能使你对这个问题看得更清晰

1. 像对一个同事一样用自然语言描述整个逻辑流程
2. 注意描述中的关键字
3. 根据描述写出对应的代码

3.4 少写代码

核心思想：最好读的代码是没有代码

• 质疑和拆分你的需求
• 保持轻量级的代码库
  • 创建越多越好的工具代码
  • 减少无用代码
  • 保持子项目的松耦合性
• 熟悉现有代码库和现有工具