Skip to content

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

原文链接

目录


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

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

可以使用 此查询在 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

json
{
  "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。该脚本可能如下所示:

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

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

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

结论

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

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

————————————————
版权声明:本文为 田园幻想乡 的原创文章,遵循 CC 4.0 BY-NC-SA 版权协议,转载请附上原文出处链接及本声明。
原文链接: http://truraly.fun/翻译转载/Nodejs参考架构/【3】代码规范.html


本页近半年访问量: 查询中……

发布时间:

最后更新时间:

Copyright © 2022 田园幻想乡 浙ICP备2021038778号-1