先放大佬的视频教学地址：https://github.com/biezhi/write-readable-code
本书宗旨：编写简单优雅的代码
引言
代码应该易于理解
-
可读性基本定理。
代码的写法应当使别人理解它所需的时间最小化
减少代码行数是可读性之后的目标。
可读性与其他目标并不会冲突。
1.表面层次的改进
1.1 将信息装到名字里
- 选择专业的词
- 找到富有表现力的词
- 清晰、精确
- 避免泛泛的名字
- 类似于temp这样的名字只适用于作用域很小的代码结构
- 迭代时，做到单个元素的首字母和被迭代变量一致
- 用具体的名字代替抽象的名字
- 使用前后缀来附带更多信息
- 如果一个变量是度量的话，最好带上它的单位
- 将变量的关键属性体现在它的命名上
- 决定名字的长度
- 在小的作用域里使用短的名字
- 如果一个变量有较大的作用域，那么它的名字应该包含更多的信息
- 首字母缩写的原则：团队的新成员是否能理解这个名字的含义
- 利用名字的格式来表达含义
- 对于不同的实体使用不同的命名格式
- 例如：类成员变量使用"_"做后缀来区分
- 例如：用下划线来分开ID中的单词，用连线来区分class里的单词
1.2 不会误解的名字
避免二义性的名字的出现，不会让人误解的名字是最好的名字
- 推荐使用min_和max_表示（包含）极限
- 推荐使用first_和last_表示包含的范围
- 推荐使用begin_和end_表示包含/排除范围
- 在布尔值上面加上is,has,can或should能够变得更准确
1.3 审美
-
三个原则
- 使用一致的布局，让读者很快就习惯这种风格。
- 让相似的代码看上去相似。
- 把相关的代码分组，形成代码块
- 重新安排换行来保持一致和紧凑（保持对齐）
- 用新写方法来整理不规则的内容
- 必要时使用列对齐
- 选择一个有意义的顺序并始终如一地使用它
- 让变量的顺序和html中的顺序一致
- 从“最重要”到“最不重要”
- 按字母排序
- 把代码分成“段落”
- 它将相似的代码区分开来
- 提供了可见的脚印
- 便段落之间的导航
- 一致的风格比“正确”的风格更重要
1.5 注释
注释的目的是尽量帮助读者和作者了解的一样多
- 什么不需要注释
- 不要为那些能从代码上快速推断的信息而写注释。
- 不要给不好的名字写注释，而应该直接修改名字
- 什么需要注释
- 很多好的注释仅通过“记录你的想法”就能得到
- 用来解释为什么代码写得不那么整洁
- 为代码中的瑕疵写注释
- TODO：未完成的事
- FIXME：已知的无法运行的代码
- HACK：对一个问题不得不采用的粗糙解决方案
- XXX：危险！这里有重要的问题
- 如何写注释
- 随时把代码如何改动的想法用注释记录下来
- 不管怎么想，先写下来
- 阅读这段代码，看是不是可以改进
- 不断地改进，在读者可能看不懂的地方写注释
- 给常量加注释
- 站在读者的角度写注释
- 公布可能的陷阱
- 例如：多久超时
- 例如：什么情况下会加重运行时间
- 添加“全局观”注释，主要应对于工具类、底层代码
- 包含“做什么”，“怎么做”，“为什么”这三方面
- 随时把代码如何改动的想法用注释记录下来
1.5 言简意赅的注释
注释应该有相当高的（信息/空间）率
- 让注释保持紧凑
- 避免使用不明确的代词
- 润色语言，这样同时能使注释简洁
- 精确描述函数的行为
- 用输入/输出描述特别案例
- 描述代码的意图（联系业务逻辑）
- 注释函数参数
2.简化逻辑和循环
2.1把控制流变得更可读
条件判断、循环等会让代码混乱
- 条件语句中参数的顺序
- 比较的左侧的值倾向于不断不变化
- 比较的右侧倾向于固定值
- if/else语句块的顺序
- 优先处理正逻辑
- 先处理简单逻辑，这样可以保持所有逻辑在一个屏幕可见
- 先处理可疑或者有趣的部分
- 三目运算
- 只对于简单的情况下适合
- 复杂情况下推荐使用if/else
- 对于追求最小代码行数的准则：最小化人们理解它的时间
- 避免使用do/while循环
- 从函数中提前返回
- 最小化嵌套
- 通过从函数提前返回来减少嵌套
- 减少循环内的嵌套（continue）
2.2 拆分超长的表达式
- 新增一个额外的变量来表达一个小一点的表达式
- 将一个表达式用更清晰的变量名来表示（便于理解业务逻辑的变量名）
2.3 可读性和变量
1.变量越多，越难完全判断所有变量的动向
2.变量作用域越大，追踪他们的动向话费时间越久
3.变量改变得越频繁就越难判断它的当前值
- 减少不能改进可读性的变量
- 没有价值的临时变量
- 减少中间结果
- 减少控制流变量
- 缩小变量的作用域（让你的变量对尽量少的代码可见；把大的类拆分成小的类）
- 在js中使用闭包函数
- 在js中如果声明时未使用var关键字，则这个变量将在全局作用域中
- 将定义靠近在第一次使用它的地方
- 只写一次变量
小结
- 如何找到更优雅的方式？
- 看这种技术能否从反方向解决问题
- 可以在任何见到复杂逻辑的地方大胆去拆分它。
3.重构代码
3.1 抽取与程序问题不相关的子问题
- 确定代码的最高层次目标
- 审视代码，是否为最高层次目标服务
- 如果有足够多的行数在解决不相关的子问题，那么将代码放到独立函数中
把一般代码和项目专用代码区分
3.2 重构，使代码一次只做一件事
- 不同任务的代码可以独立成函数
- 或者成为独立的段落
3.3 先用自然语言描述，再用代码去实现（橡皮鸭技术）
用自然语言解释清楚的问题能使你对这个问题看得更清晰
- 像对一个同事一样用自然语言描述整个逻辑流程
- 注意描述中的关键字
- 根据描述写出对应的代码
3.4 少写代码
核心思想：最好读的代码是没有代码
- 质疑和拆分你的需求
- 保持轻量级的代码库
- 创建越多越好的工具代码
- 减少无用代码
- 保持子项目的松耦合性
- 熟悉现有代码库和现有工具
