提高和自动化代码质量的最佳方法！

我最近和Rob Kendall 一起做了Front End Podcast（点击此处收听）。我们讨论了我非常热衷的事情：让代码变得更好！这意味着如何遵循我们指定的最佳实践和编码标准，以及如何快速、轻松、（最重要的是）自动化地完成所有这些工作。那么，我听到你问，秘诀是什么呢？这颗神奇的银弹是什么？

秘诀？使用 Linter！

这款静态代码分析工具功能强大，能够确保您的代码符合最新标准，并确保共享代码库遵循一系列选定的原则。我们将详细介绍其原理、方法和原因，并解释您现在应该如何在代码中实施此解决方案。

“棉绒”一词源于羊毛中不受欢迎的纤维和绒毛的名称。

它是什么？

Linting 是指根据一组预先设定的规则检查代码的过程。这些规则可以是编程语言相关的，也可以是项目特有的。Linting会 运行一个程序或工具来分析代码中的潜在错误。它会清晰地显示这些警告或错误，并提供修复选项。

Linting 工具对于 JavaScript 和 Python 等解释型语言尤其有用。这些语言缺少编译阶段，编译阶段通常会在执行前抛出错误，因此在这类情况下使用 Linting 工具会给你带来很大的好处。

可以使用的 Linting 工具。

现在我们知道它是什么了？该如何在项目中使用它？当然，我们需要一个针对每种语言的 Linter！嗯，你说得对！但幸运的是，每种主流语言都已经有可用的 Linter，有些甚至是与语言无关的。

您可以在此处找到详细列表：https://en.wikipedia.org/wiki/List_of_tools_for_static_code_analysis

上面列出的精选列表应该包含EsLint，这是一款流行的 JavaScript Linter，你可能听说过，或者正在使用。SonarQube是一款流行的语言无关工具，适用于从 Java 到 PHP 再到 Python 的各种语言。C# 和 .Net 通常有StyleCop和 FxCop ，它们经常一起使用。

那么，您可能已经听说过其中的一些，但是使用这些有什么好处，为什么您应该花时间将这些工具添加到您的解决方案中？

你们有些人可能会想……那 Prettier怎么样？Prettier 并非真正的 Linter，因为它本身并不检查代码。Prettier 是一个固执己见的代码格式化工具。它能节省你的时间和精力，并避免关于行长、括号位置，以及最重要的“制表符还是空格”的争论。

最棒的是，您可以根据自己的需求进行定制。它可以在开发过程中运行，也可以在提交到源代码仓库时作为步骤添加。它足够灵活，可以适应您的具体情况。

我为什么要使用它？

每个人都想编写干净的代码，他们想遵循最佳实践，他们想跟上创建代码的最新和最好的方法。

Linting对于减少错误和提高代码整体质量至关重要。它还能帮助您的代码长期保持一致，并跨团队、跨个人使用。它能够及早发现代码中的问题，并且在大多数情况下，让您知道如何修复它们！让我们来看看 Linting 的优缺点。

棉绒强度。

Linting 会标记出代码中所有未使用的变量，以及任何可能无法访问的代码片段！（您是否通过将逻辑更改为 1 == 1 的比较来测试 if 语句？）它还可以帮助查找超出数组长度的索引问题。

它能及早发现错误，我们都知道，发现错误的最佳时机是在开发过程中。错误被发现和解决的时间越长，修复的成本就越高。

棉绒检查弱点。

Linting 会产生大量的错误和警告，有时甚至和源代码行数一样多。这可能会导致大量误报，并可能阻碍您修复真正重要的问题。因此，设置规则至关重要。

Linting 会识别违反最佳实践的行为，但它不会教你这些最佳实践。开发人员可以使用 Linting 来改进他们的代码，但他们可能无法复制所建议的标准。

从实际时间和成本上来说，Linting 并不昂贵，但它会降低开发人员的工作效率，因为他们需要修复或修改代码以符合这些规则。

如何执行？

所以，这就是棘手的地方。正如我们所见，使用 linting 的概念有利有弊。你是想快速交付产品，还是遵循最佳实践来加快未来的工作进度？两者之间总是存在权衡，这一点需要牢记。

您是否希望您的团队每次更改内容后都解决所有问题？他们是否应该只需保持更改内容的整洁？或许您只是想通知他们，希望他们做出任何相关的更改？

快乐的媒介

我发现某种程度的 linting 很有用，尤其是在代码审查过程中。在代码提交审查之前修复一些基本问题，意味着不再需要人工进行常规检查。这也让我们能够专注于重要的方面，而不是主观臆断。

我们应该检查代码是否可以重构？拆分成不同的文件或函数是否会更好？文档是否足够？重要功能是否都进行了测试？代码是否可扩展且安全？

我认为我们都应该遵循童子军规则- 确保我们接触的任何代码都比我们发现时更好，这意味着我们将逐步消除任何技术债务，而不必一次性完成所有工作，也不必将其作为特定任务完成。

让您的代码比您发现它时更好。

童子军规则

我的 JavaScript 设置 - Trifecta

正如我上面提到的，JavaScript 从引入 linting 中受益匪浅，但由于 JavaScript 语言本身非常开放，因此有必要引入一些指导原则。以下是我添加到解决方案 中的配置，用于在开发过程中强制使用 linting。

我使用3 个外部库来帮助我完成我的工作。

• Husky是配置 Git Hooks 的简便方法。对于那些手动配置的人来说，在顶层配置中完成所有设置可以大大标准化和简化整个过程。

• 接下来是Lint Staged。如前所述，您希望开发人员能够找到一个合适的修复方案。如果他们正在处理某个文件，我认为我们都应该遵循童子军规则，即在重新提交之前清理代码。

• 最后，同样重要的是，Pretty Quick会在所有暂存文件上运行你的 Prettier 设置。它类似于Lint Staged，但负责格式化。

安装和配置包

好了，安装完这三个包后，你可以在package.json中添加以下几行代码。这会检查你所有 JavaScript 和 TypeScript 文件（如果你使用了它们），并在提交之前格式化你暂存的文件。如果检查器抛出任何错误，我们会将其显示给用户并阻止其继续操作！

配置 - Package.json

以上部分添加了已安装到 Git 管道中的工具。Husky 是我们的中间人，您可以看到，在其hooks部分中， pre-commit hook 配置为在已暂存的文件上 运行PrettyQuick ，并在之后运行Lint-Staged部分。这会对指定的 glob运行eslint和tslint ，在本例中，这些 glob 是它找到的所有已暂存的 .ts 和 .js 文件。

最后，我们必须制定在此过程中要使用的规则。

TsLint 配置

这里最重要的是我们正在扩展的规则集。tslint :latest 和 tslint-angular 负责处理基本规则。我们可以覆盖下面任何基本规则，我建议您自己找到一个合适的平衡点。我保留了一些对我来说有意义的规则。

需要tslint-config-prettier， 这样 tslint才不会格式化我们的代码，这是 Prettier 的工作，也是 prettier 配置发挥作用的地方。

Prettier 配置

放置 Prettier 配置的最佳位置是 .pretterrc 文件。我已展示了一组简单的规则来帮助您入门。Prettier配置文档是根据您的需求定制设置的最佳参考。

结果如何？

运行效果如下。你可以看到git 提交启动了 Husky，然后 Husky 又运行了我们的工具！Prettier首先修复了所有格式，然后eslint将let 修改为 const（因为它从未被重新赋值），最后将类级别声明移到了文件顶部！是不是很酷炫！

总而言之，希望您已经理解了什么是 linting、为什么要使用它以及如何使其适应您的编码环境！

我很想听听你还有其他适合你的设置！总有改进的空间。请在下方分享你的想法！

资料来源及延伸阅读

• https://en.wikipedia.org/wiki/Lint_(software)
• https://deviq.com/boy-scout-rule/
• https://stackoverflow.com/questions/8503559/what-is-linting