《编写可读代码的艺术》（《The Art of Readable Code》）

https://github.com/trekhleb/state-of-the-art-shitcode/blob/master/README.zh-CN.md 《代码整洁之道》

1、命名规范：变量、方法（方法名+形参）、类 2、代码逻辑上的优化 3、函数级别的代码组织优化。 4、 5、 6、 7、

命名规范：变量、方法（方法名+形参）、类

如： 一般用词 更加丰富多义的词语 send deliver, dispatch, announce, distribute, route find search, extract, locate, recover start launch, create, begin, open make create, set up, build, generate, compose, add, new

命名可以加入什么信息： 单位

命名的长度 1、丢弃无用词汇 2、短范围配短名字 3、使用经典的缩写 缩写 完整 str string doc document eq equal

一般常量都是以大写 + 下划线来命名的

命名的歧义 filter()、select()、 exclude() clip、clipTail、clipTo

如果要有个表示上下限变量，max/min 前缀是个好选择。 如果是表示 [n, m] 这个区间，用 first/last 比较好。 如果是表示 [n, m) 这个区间，用 begin/ending,end 比较好。 命名一个布尔值变量，善用 can, is, has 等修饰。同时，否定意味的词，例如 disable_ssl，noSync 尽量不用。

由于一些约定俗成的规则，阅读者还是容易对一个词产生惯性思维。例如 get(), List::size()，会传递一个 轻量操作 的错误信息。 我们可以使用 computeXXX()、 allocateXXX() 、fetchxxx() 修改命名，告诉阅读者函数的意图。同时也可以修改函数实现来贴合这些约定俗成的规则。

代码逻辑上的优化

条件语句组织顺序大致三种： 简单先行 错误先抛 正先否后

尽量使用 提前 return 的思想。

拆分过长的表达式：利用 变量 来简化表达式，以提升代码可读性。

逻辑关系之变化 1、德摩根律 2、短路逻辑不要滥用 3、取反：正想逻辑过于复杂，可以用：反向逻辑 再取反（其实就是德摩根律）：当发现一个判断条件参数过多，就要考虑它的反逻辑，也许更加简洁。

变量多，那就减少：无价值的临时变量 作用域太大，那就缩小：变量对尽量少的代码可见 压缩变量作用域，我们可以在使用变量的逻辑前，再声明变量，将变量的作用域就固定在变量被使用的几行代码内 变量在越少 不同 的地方被使用、赋值，定位它的变化就越容易。

奥古斯都·德·摩根首先发现了在命题逻辑中存在着下面这些关系： 非(P 且 Q) = (非 P) 或 (非 Q) 非(P 或 Q) = (非 P) 且 (非 Q)

函数级别的代码组织优化。

专注于函数的目的：我们需要将对于目的而言 相关性较小的子问题 抽取出来，变成一个独立的函数，甚至是库。这个取决于这个子问题使用的范围是一个文件，还是一整个项目。 一次只做一件事：让代码 保持单纯，抽取不相干子问题，让代码段尽量一次只做一件事