【机翻转载】【3】代码规范

原文链接

目录

• 为什么代码一致性很重要？
• ESLint
  • 将 ESLint 添加到 Node.js 项目
  • 自动化代码 linter
  • 结论

---

欢迎回到我们正在进行的关于 Node.js 参考架构的系列。第 1 部分介绍了 Node.js 参考体系结构的全部内容，第 2 部分介绍了日志记录。在本文中，我们将深入探讨代码一致性，以及如何使用 ESLint 等 linter 工具强制执行代码一致性。

为什么代码一致性很重要？

作为一个团队有效地处理 JavaScript 项目的一个关键方面是代码格式的一致性。这确保了当不同的团队成员在共享代码库上进行协作时，他们知道预期的编码模式，从而使他们能够更高效地工作。缺乏一致性会增加开发人员的学习曲线，并可能偏离主要项目目标。

当 Red Hat 和 IBM 的 Node.js 团队开始讨论代码一致性时，很快就发现这是一个人们有强烈意见的领域，一种尺寸并不适合所有人。令人惊讶的是，您可以花多少时间谈论支架的正确位置！

不过，我们可以同意的一件事是，在项目中使用一致的风格并通过自动化来强制执行它的重要性。

ESLint

在调查 Red Hat 和 IBM 用于检查和强制执行代码一致性的工具时，ESLint 很快成为最受欢迎的选择。这个可配置的 linter 工具可以分析代码以识别 JavaScript 模式并保持质量。

虽然我们发现不同的团队使用不同的代码风格，但他们中的许多人报告说他们使用 ESLint 来完成工作。ESLint 是由 OpenJS 基金会托管的开源项目，证实了它是开放治理的可靠选择。我们知道，我们总是有机会贡献修复程序并参与到项目中来。

ESLint 附带了许多预先存在的代码样式配置，您可以轻松地将它们添加到您的项目中。使用这些可共享配置之一有很多好处。通过使用现有配置，可以避免“重新发明轮子”;其他人可能已经创建了您要查找的配置。另一个优点是，新的团队成员（或开源贡献者）可能已经熟悉您正在使用的配置，使他们能够更快地上手。

以下是一些可帮助您入门的常见配置：

• eslint-config-airbnb-standard
• eslint-config-semistandard
• eslint-config-standard
• eslint-config-prettier | Github

可以使用 此查询在 npmjs.org 上找到完整列表。

请注意，我们不建议使用任何特定的代码样式或 ESLint 配置。更重要的是，您要选择一个标准，并在整个组织中一致地应用它。如果这是不可能的，那么你至少应该确保它在相关项目中一致地使用。

在这一点上，我必须承认，我们并没有真正花那么多时间讨论括号应该去哪里。但这就是我们建议查看现有配置之一的原因之一：采用现有的最佳实践可以节省大量时间（和参数），因此您可以将时间花在编码上。

将 ESLint 添加到 Node.js 项目

根据参考架构中的建议，红帽 Node.js 团队最近更新了 NodeShift 项目 | Github以使用 ESLint。

将 ESLint 添加到您的项目中是一个非常简单的过程。事实上，ESLint 有一个向导，你可以在命令行界面上运行它来帮助你入门。您可以运行：

$ npx eslint --init

，然后按照提示操作。这篇文章不会详细介绍向导 init 的细节，但您可以在 ESLint 文档中找到更多信息。

我们的团队喜欢使用分号，所以我们决定使用 semistandard 配置。通过运行以下命令可以轻松安装：

$ npx install-peerdeps --dev eslint-config-semistandard

然后，在我们的 .eslintrc.json | Github 文件中，我们确保扩展 semistandard ：

{
  "extends": "semistandard",
  "rules": {
    "prefer-const": "error",
    "block-scoped-var": "error",
    "prefer-template": "warn",
    "no-unneeded-ternary": "warn",
    "no-use-before-define": ["error", "nofunc"]
  }
}

您会注意到，我们还设置了一些自定义规则。如果您的项目有自定义规则，则应将其放在此处。

自动化代码 linter

有一个 linter 是很好的，但只有当你运行它时它才有效。虽然您可以手动运行该 eslint 命令来检查代码的一致性，但记住以这种方式运行它可能会变得繁琐且容易出错。最好的方法是设置某种类型的自动化。

第一步是创建一个这样的 pretest npm 脚本，以确保在运行测试之前进行 linting。该脚本可能如下所示：

    "scripts": {
        "pretest": "eslint --ignore-path .gitignore ."
    }

请注意，我们告诉 ESLint 忽略文件 .gitignore 中包含的路径，因此请确保 node_modules 文件夹和其他派生文件包含在该忽略文件中。使用这样的 npm 脚本可以轻松集成到大多数持续集成 （CI） 平台中。

另一种选择是配置钩子，以便在提交代码之前运行 linter。像 Husky 这样的图书馆可以帮助完成这个工作流程。只要确保这些预提交检查不会花费太长时间，否则您的开发人员可能会抱怨。

结论

确保在所有项目中实施一致的代码标准至关重要，这样您的团队才能高效协作。跟上该任务的最佳方法是使用 linter 并将其自动化为工作流程的一部分。我们推荐 ESLint，但您可以自由选择任何您想要的工具——只要您有东西。

本系列的下一期关于 Node.js 参考架构，将介绍 Node.js 生态系统中的 GraphQL。