day36 静态类型检查：ESLint语法规则和代码风格的检查

代码规范工具

在编程中 “lint” 这个术语指的是虽然可以运行，但从某种程度上不是最优的代码。这些代码可能引起潜在问题，如 bug、安全隐患，或者可读性问题。linter 是一种检测代码中是否含有问题代码的工具。linting 则是在代码上运行 linter 工具，然后修复代码、去除问题代码，直到 linter 不再报错的整个过程。
lint 并不是 JavaScript 的专有名词。它来源于 C 语言。
由于JavaScript 是一个相对灵活轻量的语言，这是它的优点，但同时也是不足。因为它没有像 C 或 Java 语言一样的严谨，所以特别是对于大型项目来说，这种灵活性也就代表开发者自身成了用好这门语言的第一责任人。而且除了语言定义上缺乏严谨性外，JavaScript 本身也没有官方的编译器，所以时至今日，linting 仍然是代码检查中需要单独工具来处理的一项重要工作。
JSLint：一个早期的 JavaScript 代码质量检查工具。它的工作原理就是对源代码进行扫描，如果发现潜在问题，就返回问题在源码中的大致位置和描述。

在后来的发展中，ESLint 逐渐成为了更加受欢迎的一个 linter 工具。
ESLint 最核心的模块是 Linter、CLIEngine 和 RuleTester。
Linter 是核心中的核心，它没有文件 I/O，也不与控制台直接交互。它的主要工作就是根据配置的选项来进行代码验证。
CLIEngine 的主要作用是找到源代码文件和配置文件，它包含了配置文件、解析器、插件和格式器的加载逻辑。ESLint 使用的是 Espree 的解析器。
RuleTester 的作用是对每一条检查规则做单元测试，RuleTester 内部包装的是 Mocha，对，你没看错，ESLint 用 Mocha 作为内部的单元测试工具。RuleTester 效仿 Mocha 的接口，可以与 Mocha 的全局测试方法一起使用。当然除了 Mocha 以外，RuleTester 也可以和其它的单元测试工具结合使用。

下面我们再来看看 ESLint、API 和 CLI 的关系。ESLint 是通过命令行来执行的文件，实际上它只是一个将命令行作为参数传递给 CLI 的包装器。CLI 接收到参数后，使用 ESLint 执行命令。API 是 require("esint") 的入口，它暴露的对象包括了 Linter、ESLint、RuleTester 和 Source Code 的公共类。
Source Code 和 Rules。顾名思义，它们分别代表了源代码和代码测试的内置规则。

代码规范检查

下面，我们就可以具体看看 ESLint 的安装和使用步骤了。首先，通过执行以下命令来安装 ESLint。
npm init @eslint/config
在初始化的过程中，ESLint 会问使用的场景、模块化的类型、项目所使用的框架、是否有使用 TypeScript、代码运行的环境和 config 文件的格式等等。之后，程序会检查之前有没有 ESLint 的本地安装。如果没有，就会先进行安装。安装前可以选择相关的包管理工具，这里，我使用的是 NPM，除此之外，有些同学也可能选择 YARN。在一系列的选择之后，ESLint 就会运行并完成安装。

之后，我们通过下面的命令，便可执行代码检查。
npx eslint yourfile.js

代码规范类型

那么在检查中，通常会有哪些类型的报错呢？这里，我们先了解下代码规范的目的。因为按照测试驱动的设计思想，如果没有相关的测试目的，那么检查和报错也就无从谈起了。总结来说，代码规范通常有这样两个目的：

• 提高代码的质量；
• 统一代码的风格。

我们可以通过下面的示例代码来看两个例子。第一个例子，使用 constructor 来构建函数，同 eval() 类似，会使得字符串的内容可能被执行。所以这个例子不仅是代码质量问题，甚至会有安全隐患。

// bad
const add = new Function('a', 'b', 'return a + b');

// still bad
const subtract = Function('a', 'b', 'return a - b');

在下面的例子中，第一行的对象字面量的表达非常长。虽然代码本身的质量没问题，但是这么长的句子会影响代码的可读性。而第二种写法则更加可读。所以通常 linter 工具会要求一行代码的长度不要超过 80 个字符。这样，可以提高代码的可读性。
在代码编写过程中，更多的关注代码易阅读性；压缩代码大小通常是在打包编译时关注。

// Bad 
const foo = { "bar": "This is a bar.", "baz": { "qux": "This is a qux" }, "difficult": "to read" }; 

// Good
const foo = {
  "bar": "This is a bar.", 
  "baz": { "qux": "This is a qux" }, 
  "difficult": "to read" 
}; 

从上面的例子中，我们可以看到 linter 是一种可以让我们的代码变得更好的方式。但是类似这样的问题，在 JavaScript 中有很多。同时在有些时候，大家对“好”的定义可能还不一样。那么遇到这么庞大的规则数量，以及大家对代码风格的不同定义，应该怎么处理呢？
ESLint 已经帮助我们整理了一些常用的规则，我们可以将 ESLint 内置的规则作为一个基准，在上面做相关的定制。在内置的规则中，分为问题、建议、布局和格式。问题和建议的目的主要是提高代码质量，布局和格式的目的主要是统一代码编写风格。
在个人开发的情况下，也应该形成自己的前后一致的风格；在团队中，应该遵循团队的统一代码规范。

通过插件的方式，ESLint 也可以作为插件和 Angular、React 等三方库结合使用。

代码规范化工具

我们在用到 ESLint 时，核心的诉求还是写出更高质量的代码，其次才是代码的美化。一些项目使用 linter 的原因之一是为了实施一致的编码风格，这样当一个开发团队在共享同一个产品或项目代码库的时候，他们就可以使用兼容的代码约定。这包括代码缩进规则，但也可以包括应该用单引号还是双引号，以及 for 关键字和其后的右括号之间是否应该有空格之类的规则。除了 linter 这种代码检查类的工具外，还有一种代码规范化的工具，其中一个例子就是 Prettier。它的工作原理也是对代码进行解析和格式化。例如我们编写了下面的函数，从功能层面讲，它是有效的，但格式不符合常规。

function HelloWorld({greeting = "hello", greeted = '"World"', silent = false, onMouseOver,}) {
}

在此代码上运行 Prettier 可以修复缩进，添加缺少的换行，让代码更加可读。

function HelloWorld({
  greeting = "hello",
  greeted = '"World"',
  silent = false,
  onMouseOver,
}) {}

在使用 Prettier 的时候，如果使用 --write 选项调用，会就地格式化指定的文件，而不是复制后格式化。如果你是用 Git 来管理源代码的话，则可以在代码提交的 hook 中使用 --write 选项来调用 Prettier，它可以让我们在代码提交前自动格式化代码。如果将代码编辑器配置为在每次保存文件时自动运行，则会更加方便。

Prettier 是可配置的，你可以选择代码行的长度限制、缩进量，是否应使用分号，字符串是应该通过单引号还是双引号包裹。虽然它只有几个选项，但总的来说，Prettier 的默认选项非常合理，不需要特别多的改动就可以达到想要的效果。同时，Prettier 也可以通过 eslint-config-prettier 和前面我们说到的 ESLint 结合使用。

此文章为2月Day14学习笔记，内容来源于极客时间《Jvascript进阶实战课》，大家共同进步💪💪