[第32期] 如何改善既有 JS 代码：修复常见的 ESLint 报警（四）

前言

ESLint 是目前最主流、最强大的 JS 代码校验工具。当我们的代码触发了 ESLint 的报警规则时，ESLint 就会提示错误。

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

no-fallthrough

禁止在 switch/case 语句中使用穿透特性。

我们在 JS（以及大多数类 C 语言）里写 switch/case 往往会踩的一个坑就是 “穿透”。简单解释一下，在 swithc 的执行过程中，匹配了一个 case 并执行完这个 case 的代码之后，如果没有遇到 break 语句，则会继续执行后续所有 case 的代码。

这是一个非常反直觉的设计，也是 bug 的温床。因此 ESLint 提供了 no-fallthrough 这条规则，避免无意中踩到穿透特性的坑。

但如果在某些场景下，你真的需要这个特性怎么办？ESLint 允许你通过注释来说明你是真的在利用穿透特性，只要注释符合特定格式就可以抑制报警：

switch (foobar) {
    case 1:
        doSomething()
        // fall through

    case 2:
        doSomethingElse()
}

no-undef

禁止使用未定义的变量。

当我们在使用一个变量之前忘了声明它，这条规则就会报警提醒我们。不过大多数触发报警的代码是在引用一个全局变量，而 ESLint 并未理解。

比如有以下代码：

// namespace
window.Auth = { /* ... */ }

// ...

// init
if (page && Auth[page]) {
    Auth[page]()
}

在后面这个 if 语句中有对 Auth 的引用。虽然我们在第一行已经定义了 Auth 这个全局变量（window.Auth = ...），但 ESLint 无法识别，这条规则会报警。

有两种方式可以修复这个问题。

改成局部变量

在引用全局变量时，先把它存到一个局部变量中：

// init
const Auth = window.Auth
if (page && Auth[page]) {
    Auth[page]()
}

通过注释声明全局变量

ESLint 可以识别文件顶部的一些特定注释，我们可以用注释来告诉 ESLint 当前环境有哪些全局变量。比如我们在文件顶部写出这一行注释：

/* global Auth */

就可以声明 Auth 是一个全局变量。如果有多个全局变量需要声明，可以以逗号分隔。

一般来说，我会推荐以后一种方式来修复报警。它的好处有以下一些：

• 不需要修改代码，只需要加注释。对于那些变更频率很低的老代码来说，修复成本自然是越小越好。

• 意图比较明确——我们就是为了抑制 ESLint 对 “引用全局变量” 的报警。

• 如果将来要消灭代码中的全局变量，这些注释都是非常好的线索。

结语

我们团队很早就开始采用 ESLint 作为 JS 代码的质量保障工具了，去年我又在此基础上开始梳理相关的规范和文档、总结相关的经验和收获。

在落地 ESLint 的过程中，最棘手的可能就是老代码的迁移了。我们团队也不例外，曾专门组织 “集体行动” 去消灭老代码的报警问题。我把团队在这个过程中遇到的实际问题和处理方法提炼出来，形成了这个系列的四篇文章，希望能为你提供参考价值。

ESLint 是个好东西，希望每个团队都能用起来。未来如果有机会，我还会跟大家继续分享这方面的心得：“如何在团队中顺利推行 ESLint”，“如何选择真正适合自己的 ESLint 规则” 等等。欢迎继续关注，下次再见！

本系列的其它文章

• [第29期] 如何改善既有 JS 代码：修复常见的 ESLint 报警（一）

• [第30期] 如何改善既有 JS 代码：修复常见的 ESLint 报警（二）

• [第31期] 如何改善既有 JS 代码：修复常见的 ESLint 报警（三）

本文仅为作者个人观点，不代表百姓网立场。

（题图来源：StockSnap @ Pixabay）

原文始发于微信公众号（百姓网技术团队）：[第32期] 如何改善既有 JS 代码：修复常见的 ESLint 报警（四）