编写自己的代码规则

项目开发到一定阶段，就需要投入资源构建代码保护机制。这个时机难以精确定义，大致是在项目长期稳定运行，一些问题开始显现，但尚未完全陷入混乱之前。避免过早优化，也避免，嗯，过晚优化。

一些工具非常易于实施，通常在项目早期就可应用。例如Prettier代码格式化工具，能实时保持代码规范。还有许多类似的工具，可在编码过程中直接使用，比如可访问性、兼容性、安全性的代码检查等等。Webhint整合了大量此类工具，值得一试。

还有一些工具需要编写更多代码来保护你的代码。测试是其中的重要部分，甚至可以设置为在编码过程中运行。测试确保代码按预期运行，因此具有极高的价值。

本文重点讨论通过编写更多代码来保护代码，但这并非传统的测试，而是自定义代码检查规则。最近我接触到两篇关于自定义代码检查规则的文章：

• Benedict Quinn 的“如何编写自定义ESLint规则”
• Omri Lavi 的“自定义Stylelint规则——编写你的第一个规则”

我主要在代码库中使用ESLint和Stylelint。但需要提醒的是，我发现这两个工具的自定义规则编写过程相当复杂。你需要了解抽象语法树(AST)。这与if (rules.find.selector.startsWith("old")) throw("Deprecated selector.")这种简单的语句完全不同。

这让我联想到一个有趣的问题：

我们团队正在维护一个旧项目，希望移除许多旧的、有问题的CSS选择器。例如，有人打开HTML文件，看到一个class名为deprecated-selector的元素，我们的目标是让IDE将其标记为代码检查错误，并提示“这是一个已弃用的选择器，请使用.ui-fresh\_\_selector代替”。

我首先想到的是编写一个自定义Stylelint规则，查找团队已知的已弃用选择器并发出警告。但不幸的是，Stylelint用于检查CSS，而这里的主要问题似乎在于HTML。我知道html-inspector可以编写自定义规则，但它已经有点过时了，所以我不确定是否能成功。

以上是编写自己的代码规则的详细内容。更多信息请关注PHP中文网其他相关文章！