在一个项目中，有一段时间是值得投资于工具来保护代码库的。我不知道该怎么说，但这是在项目被证明是长期的、粗糙的边缘开始显现之后，在事情感觉完全混乱之前。避免过早的优化，但也要避免，呃，过早的优化。
有些工具是很容易实现的，它往往是在前期就完成的。我想到了Prettier，它是一种代码格式化工具，可以使你的代码保持形状，通常是在你编码的时候。有一整套的工具可以放在 "你正在编码 "的桶里，比如可访问性检查、兼容性检查、安全检查等等。Webhint将这些工具捆绑在一起，可能值得一看。
然后是通过更多的代码来保护你的代码的工具，你必须要写。测试是这里的重要角色，甚至可以设置为在你写代码时运行。它们是为了确保你的代码做了它应该做的事情，因此，提供了大量的价值。
用你写的更多的代码来保护你的代码是我想做的事情，不是用传统的测试，而是用自定义提示规则。我想到了这个问题，因为最近有两篇关于自定义提示的不同帖子在我的办公桌上出现。
- "Benedict Quinn的"如何编写一个自定义的ESLint规则
- Omri Lavi的"自定义Stylelint规则--写你的第一个"。
作为一个在我的主要代码库中同时使用ESLint和Stylelint的用户，我很感兴趣。但是，我发现在这两个地方编写自定义规则的过程非常困难。你必须了解你在抽象语法树中的方法。它不像if (rules.find.selector.startsWith("old")) throw("Deprecated selector.") 或类似的东西那么简单。
我发现这一切与我遇到的一个有趣的问题有关。
我在一个开发团队中工作，正在处理一个老项目，我们想摆脱许多最老和最有问题的CSS选择器。例如，我们中的一个人可能会打开一个HTML文件，看到一个类名为
deprecated-selector的元素，我们的目标是让我们的IDE把它标记为一个linting错误，并说 "这是一个废弃的选择器，用.ui-fresh__selector来代替"。
我首先想到的是一个自定义的Stylelint规则，它可以寻找你的团队知道的被废弃的选择器并警告你。但不幸的是，Stylelint是用来检查CSS的，听起来这里的主要问题是HTML。我知道html-inspector有一种写自己的规则的方法，但它已经有点过时了，所以我不知道在那里是否能找到成功。
Writeing Your Own Code Rules一文出现在CSS-Tricks上。你可以通过成为MVP支持者来支持CSS-Tricks。
