简谈提高团队代码质量的利器：ESLint 与 Prettier-烟雨网

每个开发人员都有独特的代码编写风格和不同的文本编辑器。在团队项目开发过程，不能强迫每个团队成员都写一样的代码风格。

可能会看到以下部分（或全部）内容：

缺少分号；
有单引号、双引号，风格不一致；
一些行之间有大量的空格，而其他行之间没有空格；
在使向右滚动多年以查看其中包含的所有内容的行上运行；
看似随意的缩进；
注释掉代码块；
初始化但未使用的变量；
一些使用“严格”JS 的文件和其他不使用的文件；
代码块在任何地方都没有空格或注释，这使得阅读它们和破译正在发生的事情变得更加困难。

那么如何解决同一项目中有太多不同编码风格的问题？希望实现相同的编码风格，避免团队成员之间的许多警告；有 2 个非常简单的利器：ESLint 和 Prettier。

在 Visual Studio Code 中、安装插件 Prettier 和 ESLint 的帮助下消除一群不同开发人员的代码不一致，为开发团队提供一套整洁、统一的代码格式化。

ESLint

ESLint 是一个开源的 JavaScript 代码检查工具，由 Nicholas C. Zakas 于2013年6月创建。代码检查是一种静态的分析，常用于寻找有问题的模式或者代码，并且不依赖于具体的编码风格。对大多数编程语言来说都会有代码检查，一般来说编译程序会内置检查工具。

ESLint 非常适合希望开发团队遵守的更具体、更通用的代码样式。除非专门设置它，否则 ESLint 不会自动修复或重写项目的代码，但它会以一种直接的方式让你知道有“规则”被打破了（不符合）。

这里分享一个 VUE 项目的规则：

{
    indent: ["off", 2],
    quotes: [0, "single"],
    "no-mixed-spaces-and-tabs": [2, false], // 禁止混用tab和空格
    "generator-star-spacing": "off",
    "no-debugger": process.env.NODE_ENV === "production" ? "error" : "off",
    "no-console": process.env.NODE_ENV === "production" ? "error" : "off",
    "space-before-function-paren": "off",
    "no-var": "off", // 使用let和const代替var
    "no-new-func": "error", // 不允许使用new Function
    camelcase: [0, { properties: "never" }],
    "comma-dangle": ["error", "only-multiline"],
    semi: [2, "always"], // 语句强制分号结尾
    "prettier/prettier": [
        "off",
        {
            singleQuote: false,
            semi: false,
            trailingComma: "none",
            bracketSpacing: true,
            jsxBracketSameLine: true,
        },
    ],
}

Prettier

一个流行的代码格式化工具的名称，它能够解析代码，使用你自己设定的规则来重新打印出格式规范的代码。可以为项目定义一下规则：

将所有单引号更改为双引号，
添加缺少的分号，
在大括号或方括号和变量之间放置空格，
设置标准标签宽度。

上面只是 Prettier 规则的很小部分，在 VS Code 中，可以很容易覆盖任何你不喜欢的规则。

Prettier 是为了保持代码格式一致的 VS Code 插件，它可以 .prettierrc 在项目中有或没有文件的情况下工作（尽管这对于在代码库上工作的开发团队来说可能是一个很好的建议）。它将使项目的代码保持干净和易于阅读，并且在团队中的所有开发人员中都一样。

ESLint 与 Prettier

ESlint 不仅仅是一个代码格式化程序，它还可以帮助开发人员发现编码错误。例如，如果在没有声明的情况下使用变量，ESLint 会给你一个警告。Prettier 没有这样的能力。
ESLint 会让开发人员知道代码格式有什么问题，并为其提供解决问题的选项。然后可以从这些选项中选择一个。另一方面，Prettier 根本不关心你。它只是将所有代码格式化为不同的结构格式。
Prettier 中的整个重写过程可以防止开发人员犯任何错误。
max-len、no-mixed-spaces-and-tabs、keyword-spacing、comma-style 是 Prettier 中一些流行的格式规则。
除了上述类型的规则，ESLint 还考虑了代码质量规则，例如 no-unused-vars、no-extra-bind、no-implicit-globals、prefer-promise-reject-errors。