如何改善既有 JS 代码：修复常见的 ESLint 报警（一）

cssmagic commented 6 years ago

前言

ESLint 是目前最流行、最强大的 JS 代码校验工具。它不仅可以帮助我们统一代码风格，更重要的是，它还可以帮助我们发现代码中可能存在的错误。

当我们根据自己的需要设置好 ESLint 的报警规则，并集成到编辑器（或构建工具）之后，ESLint 就开始为我们服务了——在开发时（或构建时）对我们的代码给出校验结果、提示错误。

在 ESLint 提供的这些规则中，有些是可以一键自动修复的，而有些则需要我们手工介入，针对性地修复有问题的 JS 代码。

本系列文章将详细讲解那些需要手工介入修复的 ESLint 规则，帮助你把既有代码顺利迁移到 ESLint 的保护之中。

`eqeqeq`

这条规则要求我们把 “模糊判断” 改为 “精确判断”。它是最常用的 ESLint 校验规则之一。

大家都知道，== 具有隐式的类型转换能力（比如 2 == '2' 判断成立），因此当我们需要 “模糊地” 对比两个值时，往往倾向于使用 == 和 !=。

举个很常见的例子，我们不确定后端接口给出的某个值到底是数字还是字符串，往往会这样写：

if (response.errorCode == 0) {
    // do something...  
}

这种写法看起来很好用，为什么还要禁止它呢？问题在于 == 和 != 所采用的那一套类型转换规则远比我们想像的复杂。比如说，我们很难一眼看出 null == 0 的判断结果如何。这种隐式的复杂度很容易让我们踩坑，因此很多团队的代码规范都要求放弃使用 == 和 !=。

好，既然如此，我们接下来看看如何去掉代码中的这些 == 吧！

其实方法并不复杂，如果我们需要做 “跨类型” 比较，就先显式地把类型转换一致吧：

if (parseInt(response.errorCode, 10) === 0) {
    // do something...  
}

或者这样：

if (String(response.errorCode) === '0') {
    // do something...  
}

`no-bitwise`

这条规则会禁用所有位运算符。

“位运算” 在日常开发中并不常用，如果我们在代码中写出位运算符，多半是手滑敲错了，或者是为了耍帅。比如，用它写一个 IIFE（立即调用的函数表达式）：

~function () {
    // do something...
}()

这种写法确实很帅，因为它令新手不明觉厉，尊你为大神。然而我们的追求不应该是 “不明觉厉”，而应该是 “一目了然”。因此，建议你用其它模式来写 IIFE。

比如，如果你采用传统的写行末分号的代码风格，可以采用传统的 IIFE 书写方式：

(function () {
    // do something...
})();

如果你的风格是不写行末分号，则可以这样写：

void function () {
    // do something...
}()

`no-implicit-coercion`

这条规则可以禁止隐式的类型转换，包括用 ~ 位运算判断 -1 的做法。

有一个关于 ~ 位运算的奇技淫巧——它可以判断一个数字是否为 -1。它在配合字符串或数组的 .indexOf() 方法时，非常炫酷：

// 判断字符串的包含关系
if (~str.indexOf(substr)) {
    // do something...
}

然而这种写法并不易读，而且会触发 no-implicit-coercion 这条规则报警（显然也会触发上面那条 no-bitwise 规则）。

建议采用更加直观的写法：

if (str.indexOf(substr) !== -1) {
    // do something...
}

或者采用 ES6+ 为字符串和数组提供的新方法 .includes()：

// 判断字符串的包含关系
if (str.includes(substr)) {
    // do something...
}

或者采用第三方类库提供的 API：

// 判断数组是否包含某个成员
// jQuery / Zepto
if ($.inArray(member, array)) {
    // do something...
}
// Underscore / Lodash
if (_.includes(array, member)) {
    // do something...
}

// 判断字符串的包含关系
// Gearbox
if (gearbox.str.includes(str, substr)) {
    // do something...
}

如你所见，这些建议的写法都比那个神秘的波浪号直观多了。

（待续……）