本书让人感受到，代码写的好不好，并不是要写的花里胡哨，自己看着舒服别人看着头大的，本书旨在帮助你把代码写得更好，简单来讲 代码应该写得容易理解
一段代码写方式好不好是以使别人理解它所需的时间长段来决定
比如： if语句，用取正比取反更让人理解
在没有太多区别的情况下尽量 取正， 逆向思维肯定是更难理解的
if(isShow) {
}
if (!isShow) {
}把信息塞入名字中，读者仅通过读到名字就可以获得大量信息
• 使用专业的单词——例如，不用Get，而用Fetch或者Download可能会更好，这由上下文决定。
• 避免空泛的名字，像tmp和retval，除非使用它们有特殊的理由。
• 使用具体的名字来更细致地描述事物——ServerCanStart()这个名字就比CanListenOnPort更不清楚。
• 给变量名带上重要的细节——例如，在值为毫秒的变量后面加上_ms，或者在还需要转义的，未处理的变量前面加上raw_。
• 为作用域大的名字采用更长的名字——不要用让人费解的一个或两个字母的名字来命名在几屏之间都可见的变量。对于只存在于几行之间的变量用短一点的名字更好。
• 有目的地使用大小写、下划线等——例如，你可以在类成员和局部变量后面加上"_"来区分它们。
不会误解的名字是最好的名字
当要定义一个值的上限或下限时，max_和min_是很好的前缀。对于包含的范围，first和last是好的选择。对于包含/排除范围，begin和end是最好的选择，因为它们最常用
当为布尔值命名时，使用is和has这样的词来明确表示它是个布尔值，避免使用反义的词（例如disable_ssl）。要小心用户对特定词的期望。例如，用户会期望get()或者size()是轻量的方法。
大家都愿意读有美感的代码。通过把代码用一致的、有意义的方式“格式化”，可以把代码变得更容易读，并且可以读得更快
- 如果多个代码块做相似的事情，尝试让它们有同样的剪影。
- 把代码按“列”对齐可以让代码更容易浏览。
- 如果在一段代码中提到A、B和C，那么不要在另一段中说B、C和A。选择一个有意义的顺序，并始终用这样的顺序。
- 用空行来把大块代码分成逻辑上的“段落”。
注释
注释的目的是帮助读者了解作者在写代码时已经知道的那些事情。本章介绍了如何发现所有的并不那么明显的信息块并且把它们写下来
什么地方不需要注释：
- 能从代码本身中迅速地推断的事实。
- 用来粉饰烂代码（例如蹩脚的函数名）的“拐杖式注释”——应该把代码改好。
- 对于为什么代码写成这样而不是那样的内在理由（“指导性批注”）。
- 代码中的缺陷，使用像TODO:或者XXX:这样的标记。
- 常量背后的故事，为什么是这个值。站在读者的立场上思考：
- 预料到代码中哪些部分会让读者说：“啊？”并且给它们加上注释。
- 为普通读者意料之外的行为加上注释。
- 在文件/类的级别上使用“全局观”注释来解释所有的部分是如何一起工作的。
- 用注释来总结代码块，使读者不致迷失在细节中。
克服“作者心理阻滞” 不写注释
让代码的控制流更易读。
在写一个比较时（while (bytes_expected ＞ bytes_received)），把改变的值写在左边并且把更稳定的值写在右边更好一些（while (bytes_received ＜; bytes_expected)）。你也可以重新排列if/else语句中的语句块。通常来讲，先处理正确的/简单的/有趣的情况。有时这些准则会冲突，但是当不冲突时，这是要遵循的经验法则。
某些编程结构，像三目运算符（:?）、do/while循环，以及goto经常会导致代码的可读性变差。最好不要使用它们，因为总是有更整洁的代替方式。
eg:
嵌套的代码块需要更加集中精力去理解。每层新的嵌套都需要读者把更多的上下文“压入栈”。应该把它们改写成更加“线性”的代码来避免深嵌套。通常来讲提早返回可以减少嵌套并让代码整洁。“保护语句”（在函数顶部处理简单的情况时）尤其有用。
有些程序员认为函数中永远不应该出现多条return语句，这是没有依据的，更早返加减少嵌套
变量
引入“解释变量”来代表较长的子表达式。这种方式有三个好处：
- 它把巨大的表达式拆成小段。
- 它通过用简单的名字描述子表达式来让代码文档化。
- 它帮助读者识别代码中的主要概念。
另一个技术是用德摩根定理来操作逻辑表达式——这个技术有时可以把布尔表达式用更整洁的方式重写（例如if (!(a && !b))变成if (!a || b)）
减少变量的数量和让它们尽量“轻量级”来让代码更有可读性
- 减少变量，即那些妨碍的变量，没有价值的临时变量、减少中间结果、减少控制流变量
- 减小每个变量的作用域，越小越好。在JavaScript中创建“私有”变量。
- 只写一次的变量更好。那些只设置一次值的变量（或者const、final、常量）使得代码更容易理解。
把一般代码和项目专有的代码分开
这个技巧有帮助的原因是它使程序员关注小而定义良好的问题，这些问题已经同项目的其他部分脱离。其结果是，对于这些子问题的解决方案倾向于更加完整和正确。你也可以在以后重用它们
创建大量通用代码 如css类、业务常量
纯工具代码 如lodash
项目专有的功能
简化已有接口 ：如cookie封装
按需重塑接口 如get请求后带的参数可以写个方法里面传对象返回完整拼接
一次只做一件事情
如果你有很难读的代码，尝试把它所做的所有任务列出来。其中一些任务可以很容易地变成单独的函数（或类）。其他的可以简单地成为一个函数中的逻辑“段落”。具体如何拆分这些任务没有它们已经分开这个事实那样重要。难的是要准确地描述你的程序所做的所有这些小事
尽量越少代码越好的
每行新的代码都需要测试、写文档和维护。另外，代码库中的代码越多，它就越“重”，而且在其上开发就越难
- 从项目中消除不必要的功能，不要过度设计。
- 重新考虑需求，解决版本最简单的问题，只要能完成工作就行。
- 经常性地通读标准库的整个API，保持对它们的熟悉程度。
