Prettier 和有主见的代码格式化程序的魅力

观点鲜明的格式器的兴起

如何强制执行 Prettier

我们需要额外的棉絮吗？

你呢？

我喜欢Prettier。

它可能是对我作为程序员的生产力影响最大的单一工具（也许仅次于 Git）。

如果你还不了解 Prettier，它是一款针对 JavaScript/TypeScript、HTML、JSX 等语言的、具有特定格式化规范的代码格式化工具。它轻量级，几乎无需配置，即可自动格式化代码。从此，你再也不用花半天时间跟同事争论 HTML 嵌套、正确的行长度，或者字符串应该用单引号还是双引号了。

这是我的 Prettier 配置：

module.exports = {
  printWidth: 80,
  singleQuote: true,
  trailingComma: 'es5',
};

是不是很简单？我的设置有点主观，所以你甚至可以用更少的设置！

我用的是 VSCode，所以我把所有项目都设置成保存时自动格式化。如果你还没这么做，我强烈建议你也这么做。任何现代 IDE 都应该具备这个功能。

看到自己写的乱码 JSX 代码在保存时完美地契合到位，会有一种奇特的快感。

观点鲜明的格式器的兴起

带有预设规则的代码格式化工具很棒，因为它们能消除程序员和技术宅之间关于代码格式的无休止争论。虽然我们如此重视代码质量是好事，但总的来说，这非常浪费时间。自从我们团队开始使用 Prettier 以来，代码审查效率大大提高，我们也不再每周都进行风格方面的讨论了。

我们应该更加珍惜时间，意识到这些讨论纯属浪费时间。虽然你说的“上帝设计字符串的本意就是用双引号”或许没错，但这真的无关紧要。你浪费在讨论这个问题上的时间远远超过了使用双引号带来的好处。把这些讨论和心理负担留给 Prettier 团队吧，我保证他们已经仔细考虑过最佳默认设置是什么了。

Prettier 并不是唯一的代码格式化工具。对于 Python，我使用并非常喜欢Black。你可以查看这个 GitHub 仓库，了解其他语言的替代方案。

如何强制执行 Prettier

除了让每个团队成员都在自己的 IDE 中设置 Prettier 之外，还有很多方法可以在团队中强制使用 Prettier。如果你的团队是纯前端团队，可以使用husky 和 ​​lint-staged。如果你的团队是全栈或多语言团队，可以使用pre-commit Python 包将 Prettier 作为 pre-commit hook 运行。这意味着当你使用 git 提交代码时，所有暂存的文件都会被美化。

我们需要额外的棉絮吗？

过去，我在前端项目中大量使用ESLint ，尤其是在Airbnb 的配置方面，因为它的要求非常严格。

ESLint 的问题在于它的可配置性太强。它并没有解决风格之争，反而增加了更多选项，而我们其实并不需要那么多选项。作为 Web 开发人员，我们已经饱受决策疲劳的困扰，不得不在框架、第三方库、状态管理、不同的样式选项、REST 与 GraphQL、构建工具等等之间做出选择。

以下是一个来自实际项目的 ESLint 决策疲劳示例：

rules: {
  'react/no-unescaped-entities': 'off',
  'no-restricted-syntax': 'off',
  'no-continue': 'off',
  'no-underscore-dangle': 'off',
  'operator-linebreak': 'off',
  'implicit-arrow-linebreak': 'off',
  'react/destructuring-assignment': 'off',
  'react/no-multi-comp': 'off',
  'jsx-a11y/click-events-have-key-events': 'off',
  'jsx-a11y/no-static-element-interactions': 'off',
  'react/jsx-one-expression-per-line': 'off',
  'lines-between-class-members': ['error', 'always', { exceptAfterSingleLine: true}],
  'react/no-array-index-key': 'off',
}

ESLint 规则经常根据个人意见随意启用或禁用。要么就得写一整份 README 文件来解释为什么某些规则会被强制执行，而另一些则不会。每次有新开发人员加入，这些决定都会面临质疑。这会给每个人带来不必要的精神负担。

与 Prettier 不同，ESLint 强制执行的大部分错误无法自动修复。这使得它在持续集成 (CI) 或作为 pre-commit hook 运行时显得笨拙。它需要开发人员自行修复，从而增加了额外的手动工作。修复代码检查问题并非编码的乐趣所在。

我仍然认为 ESLint 有一些用途，但是有了 Prettier 之后，它的用途就非常有限了。我现在的配置基本上只是扩展了eslint-config-react-app （ create-react-app使用）和eslint-prettier（为了避免 Prettier 和 ESLint 规则冲突），没有修改任何额外的规则。随着 Prettier 的成熟，我最终可能会完全放弃 ESLint。

我的.eslintrc.js现在看起来是这样的：

module.exports = {
  extends: [
    'react-app',
    'plugin:prettier/recommended',
  ],
}

简单往往被低估。

你呢？

您觉得 Prettier 或其他带有特定语法规范的格式化工具对您和您的团队来说是否同样有用？您认为 ESLint（或其他代码检查工具）对于提高工作效率是必要的吗？