ESLint 规则详解

前端界大神 Nicholas C. Zakas 在 2013 年开发的 ESLint，极大地方便了大家对 Javascript 代码进行代码规范检查。这个工具包含了 200 多条 Javascript 编码规范且运行迅速，是几乎每个前端项目都必备的辅助工具。可是，这么多规则，每个规则的设计出发点是什么，我们该如何选择适合自己项目的规则，又成了新问题。前不久，我所在的项目开始对前端代码进行代码规范的要求，于是我们详细梳理了 eslint 中的 230 个规则。我摘录了其中一些比较重要或特别的规则列在这里，希望能对大家的工作有所帮助。

1.no-debugger

一般来说，我们确实不希望代码中出现 debugger，但是，debugger 在项目的开发阶段还是非常有用的，所以我们并没有完全禁用这个关键字，而是采用了这样的配置：

'no-debugger': process.env.NODE_ENV === 'production' ? 2 : 0

这样一来，开发人员可以方便地使用 debugger 在本地进行各种调试，同时有保证了线上代码不会有忘记删掉的 debugger
2.no-extra-boolean-cast

很多比较老的 javascript 代码里面可以看到这样的写法：

var boolResult = !!parameter;

这里面实际上是做了一次隐式类型转换，可是，你真的确切里面 js 隐式转换的详细规则么？事实上，在《javascript高级编程》一书里面，作者就明确警告了大家，尽量不要使用隐式类型转换，因为这个转换规则异常复杂，所以我们打开了这个规则，来避免潜在的问题
3.no-inner-declarations

ES6以前，函数声明只能在程序或另一个函数体的最前面，所以在代码块内部声明函数是错误的做法。另外，由于 javascript 中代码声明会被提升到代码当前作用域的最前面，所以在代码块内声明变量也是不明智的做法
4.use-isnan

这是很多人都容易忽略的一个点。javascript 代码中 NaN 和任何变量作比较，都会得到 false，甚至和它自身比较都会得到false。所以，要判断一个变量是否是 NaN 的时候，一定要用 isNaN 方法
5.eqeqeq

这一条可以说是每个 javascript 开发人员都必需遵守的，禁用 == 和 != 用 === 和 !== 代替。原因和上面的第 2 条一样，== 和 != 会带来隐式的类型转换，虽然 javascript 运行时并不会转换出错，但是后续维护代码的人却很可能理解错误，所以这条规则是必备的
6.no-caller

这个规则的来由就比较复杂了，简单来说，这是 ES6 之前的一个 API，这个 API 虽然帮我们解决了一些特殊场景的问题（匿名递归函数），但是，滥用这两个 API 会导致更多的问题，所以这个 API 在 ES6 已经被弃用了，在 ES5 的严格模式下也是被禁用的。如果你想详细了解这个 API 的用法，可以查看 MDN 上的详细说明
7.no-extend-native

不要扩展原生对象原型。当你在某个对象上用 for in 语句遍历对象属性，而又忘了用 hasOwnProperty 判断属性来源的时候，你就会发现被你扩展的原型属性也会被遍历出来，这往往都不是我们想要的结果
8.no-restricted-properties

这个规则事实上是一个工具，它可以禁用指定对象的指定方法。比如我们希望开发人员在发 ajax 请求的时候，全部使用我们自己封装的 ajax 方法，而不要使用 jQuery 的 ajax 方法，我们就可以通过这个配置，即使发现不符合我们规定的代码
9.no-sequences

逗号表达式其实是我们比较常用的语法特性，比如在 for 循环中。不过它也有很多容易让人犯错的用法，比如：

var a = 1, b = 1;

a = b += 3, a + b;

你知道这个时候 a 和 b 值分别是多少么？启用此规则之后，你仍然可以在 for 循环和其它一些不容易出错的场景中使用逗号表达式，不过，如果 ESLint 提示你触犯了规则，说明你就应该修改你的代码了。

另外，上面 a 和 b 的值都是 4
10.no-with

with 语句的作用是修改作用域链，虽然有时候可以用 with 语句来简化代码，比如：

with(frames[0].document.forms[1]){

console.log(name.value); // 可直接访问 form 里面的 name 属性

}

但有时候 with 语句也会让代码难以理解，比如下面这段代码里面，打印出来的 log 对象无法确认是传入的参数还是 obj 上面的属性：

function f(log, obj) {

with (obj) {

console.log(log)

}

}

所以，我们还是应该尽量避免使用 with 语句

11.no-sparse-arrays

使用代码质量检查工具的一个重要目的就是为了提高代码的可读性，或者说是降低其他人阅读并理解代码的难度，这条规则就是这样。当你看到这样一段代码 var userList = ['Tiger', 'Kate', , 'Mike']; 你真的很难确定原来写这段代码的人是不是故意要在数组中留下一个 undefined 元素，毕竟这样写并没有语法上的错误。这条规则的目的就是禁止通过这种方式在数组中插入 undefined 元素，因为这种写法太有迷惑性了。
12.no-extra-bind

如果你对 javascript 中的 this 变量有所了解，你一定也知道 bind 方法的作用，它可以很方便的帮我们修改方法执行时的上下文环境，但事实上有些时候并不需要使用 bind。如果你在一些不需要使用 bind 的地方也用 bind 来保证方法执行时的上下文环境，这会让代码执行的效率变低。所以，启用这条规则，可以帮你避免不必要的性能损失。
13.no-useless-call

和上一条规则类似，call 和 apply 也是帮助我们修改上下文环境的好工具，但我们应该只在需要修改上下文的时候才去使用这两个方法，如果你的代码检查工具发现你修改后的上下文和函数或方法原始的上下文相同，它就会给出提示。
14.yoda

yoda 表达式其实是用写争议的。有人觉得 if ('red' == color) 这样的写法可以避免程序员不小心把 == 写成了 =，但如前篇所说，我们用过在代码中禁用 ==，一律换成 ===，同时在代码检查工具的帮助下，把 == 写成 = 的可能性其实不大。而同时这样的写法在阅读时也显得比较别扭，所以我个人觉得还是禁用 yoda 表达式比较好。
15.no-delete-var

delete 操作符只能删除对象上的属性，并不能删除当前上下文中的某个变量，虽然代码不会报错，但很可能实际运行的结果和开发人员设想的不同，所以，应该明确禁止删除变量的操作。
16.no-undef

禁用未声明的变量。javascript 异常灵活，以至于你可以在没有声明一个变量的时候直接给他赋值，比如 t = 'test message'，但这样的写法却是非常危险的，因为这种写法虽然会自动生命变量 t，但他的作用域却和用 var 声明的变量作用域不同，t 变量的作用域在全局变量上，所以，不用 var 直接声明并给变量赋值，经常导致意料之外的程序 bug。
17.no-new-require

当我们使用 CommonJS 的包管理规范时，经常用 require 引入一些依赖，当我们引入的依赖是一个类定义函数时，直接在 require 上进行 new 操作很可能会引起误解。比如 var tiger = new require('User'); 和 var tiger = new (require('User')); 所以，还是禁用这种写法比较好。