【读书笔记】代码整洁之道
书名：《代码整洁之道》
作者：[美]Robert C.Martin
出版社：人民邮电出版社
出版日期：2010-05
这本书是关于什么的
作者基于自己的经验，告诉读者如何写出更易维护、错误更少的代码。
书中有一些 java 项目的重构案例。
大纲
第 1 章 整洁代码
对代码的态度
程序员遵从不了解混乱风险的经理的意愿，也是不专业的做法。
代码的混乱不应该归咎于需求侧。
破窗效应会导致代码腐坏，应该总是保持代码整洁。你走的时候，项目代码应该比你来时更加整洁。
如何保持代码整洁
代码逻辑直接了当。
尽量减少依赖关系，便于维护。
性能调至最优，省的引诱别人做没规矩的优化，搞出一堆混乱来。
别人修改糟糕的代码时，往往会越改越烂。
整洁的代码只求做好一件事。
糟糕的代码想做太多事，它意图混乱，目的含糊不清。整洁的代码力求集中（单一职责）。
完善错误处理代码。
敷衍了事的错误处理代码是程序员忽视细节的一种表现。 整洁的代码要求重视细节。
使用有意义的命名，代码是写给人看的。
应该有单元测试和验收测试。
避免重复代码。
第 2 章 有意义的命名
取好名字需要有良好的描述技巧和共有文化背景。
- 命名要具体，避免使用
list这样的命名。 - 不要使用编号进行区分，如：
name1、name2。 - 避免意义不明确的单词缩写。
- 类名和对象名应该是名词或名词短语，类名不应当是动词。
- 方法名应该是动词或动词短语，加上
get、set和is前缀，其他常用动词见编写可维护的 JavaScript。
第 3 章 函数
尽可能短小。
只做一件事。
要判断函数是否不止做了一件事，可以看是否能再拆出一个函数。
避免产生副作用（修改全局变量、修改外部对象等）。
避免修改参数本身（js 引用类型），对于转化操作应该返回一个新对象。
如果不想产生额外的内存开销可以用形如
arr.sort()的方式调用方法修改参数。避免传入标识参数。
将布尔值传入函数就等于大声宣布这个函数不止做一件事，这违反了单一职责原则。 好的做法是将函数进一步拆分。
参数控制在两个以内，一个参数最好，尽量避免三个及以上参数。
如果函数需要三个及以上的参数，应该将一些参数封装为对象。
try/catch语句之后不应该存在其他内容。死代码，永不调用的方法应该被删除。
第 4 章 注释
清除过时、废弃、不恰当的注释，避免产生误导。
不要注释代码，无用代码应该直接删掉。
其他人不敢删除注释掉的代码。他们会想，代码依然放在这一定有原因。
第 5 章 格式
第 6 章 对象和数据结构
第 7 章 错误处理
抛出的每个异常都应该提供足够的环境说明，以便判断错误的来源和所在位置。
应创建信息充分的错误消息并和异常一起传递出去。
不能让异常处理程序扰乱代码逻辑。
第 8 章 边界
第 9 章 单元测试
第 10 章 类
系统应该由许多短小的类而不是少量巨大的类组成。
每个小类封装一个权责，只有一个修改的原因，并与少数其他类一起协同达成期望的系统行为。
保持高内聚。
内聚性高，意味着类中的方法和变量互相依赖，互相结合成一个逻辑整体，而对外部的依赖小。
第 11 章 系统
- 软件系统应将起始过程和之后的运行时逻辑分离。
第 12 章 迭进
第 13 章 并发编程
第 14 章 逐步改进
第 15 章 JUnit 内幕
第 16 章 重构 SerialDate
第 17 章 味道与启发（不整洁代码的特征）
对不整洁代码特征的总结。
环境
需要多少步才能让项目跑起来。
git clone ... npm i npm run start需要多少步才能开始测试。
应当发出单个指令就可以运行全部单元测试。
一般性问题
重复代码。
基类依赖派生类。
垂直分割。
变量和函数应该在靠近被使用的地方定义，垂直距离要短。
死代码，永不执行的代码应该被删除。
遵循约定。
每个团队有有自己的编码规范，应该遵守而不是特立独行。
将边界条件集中到一处，不要散落在代码中。
总结
书中提出了一些让代码更整洁的建议，但是整体而言还是偏向 java，语言环境和前端还有较大区别。
【第 17 章 味道与启发】相当于对全书的总结，列出了不整洁代码的特征和改进方法，值得重复阅读。
前端还是更推荐 《编写可维护的 JavaScript》。
疑问
- 【3.8 分隔指令与询问】章节中指出函数不应该同时执行操作和返回信息，但是对于一个修改操作，返回一个布尔值表示操作是否成功难道不是一种更便捷的方式吗？否则怎么知道操作是否成功，抛出错误？