寻找可以监视CSS质量和复杂性的堆栈

许多开发者撰写关于如何维护 CSS 代码库的文章，但很少有人写到他们如何衡量代码库的质量。当然，我们有优秀的代码检查工具，如 StyleLint 和 CSSLint，但它们只能在微观层面防止错误。使用错误的颜色表示法、在已经使用 Autoprefixer 的情况下添加供应商前缀、以不一致的方式编写选择器……诸如此类。

我们一直在寻找改进 CSS 编写方式的方法：OOCSS、BEM、SMACSS、ITCSS、实用优先等等。但其他开发社区似乎已经从单纯的代码检查工具发展到像 SonarQube 和 PHP Mess Detector 这样的工具，而 CSS 社区仍然缺乏比浅层 lint 规则更深入的检查工具。为此，我创建了 Project Wallace，一套用于检查和强制执行 CSS 质量的工具。

Project Wallace 是什么？

Project Wallace 的核心是一组工具，包括命令行界面、代码检查器、分析器和报告器。

以下是这些工具的简要概述。

命令行界面

这允许您在命令行上运行 CSS 分析，并获取您提供给它的任何 CSS 的统计信息。

Constyble 代码检查器

这是一个专门为 CSS 设计的代码检查器。基于 Wallace 生成的分析结果，您可以设置不应超过的阈值。例如，单个 CSS 规则不应包含超过 10 个选择器，或者平均选择器复杂度不应高于 3。

分析器

Extract-CSS 正如其名：从网页中提取所有 CSS，以便我们可以将其发送到 projectwallace.com 进行分析。

报告器

Extract CSS 的所有分析结果都发送到 projectwallace.com，仪表板包含所有数据的报告。它类似于 CSS Stats，但它跟踪更多指标，并随时间推移存储结果并在仪表板中显示它们。它还显示了两个时间点之间的差异，以及许多其他功能。

分析 CSS 复杂度

关于 CSS 复杂度的文章不多，但 Harry Roberts (csswizardry) 写的那一篇让我印象深刻。其要点是每个 CSS 选择器基本上是一堆 if 语句，这让我想起了上计算机科学课程时，我必须手动计算方法的循环复杂度。Harry 的文章对我来说非常有意义，因为它可以编写一个模块来计算 CSS 选择器的复杂度——当然，不要与特异性混淆，因为在复杂度方面，这是一个完全不同的问题。

基本上，CSS 中的复杂性可以以多种形式出现，但以下是我在审核代码库时最关注的几种：

CSS 选择器的循环复杂度

选择器的每个部分都意味着浏览器需要执行另一个 if 语句。较长的选择器比较短的选择器更复杂。它们更难调试，浏览器解析速度更慢，也更难覆盖。

<code>.my-selector {} /* 1 个标识符 */
.my #super [complex^="selector"] > with ~ many :identifiers {} /* 6 个标识符 */</code>

每条规则集的声明数（内聚性）

包含许多声明的规则集比包含少量声明的规则集更复杂。Tailwind 和 Tachyons 等函数式 CSS 框架的流行，可能归因于 CSS 本身的相对“简单性”。

<code>/* 1 条规则，1 个声明 => 内聚性 = 1 */
.text-center {
  text-align: center;
}

/* 1 条规则，8 个声明 => 内聚性 = (1 / 8) = 0.125 */
.button {
  background-color: blue;
  color: white;
  padding: 1em;
  border: 1px solid;
  display: inline-block;
  font-size: normal;
  font-weight: bold;
  text-decoration: none;
}</code>

源代码行数

代码越多，复杂度越高。每一行编写的代码都需要维护，因此包含在报告中。

每条规则的平均选择器数

一条规则通常包含 1 个选择器，但有时会更多。这使得很难删除 CSS 的某些部分，从而使其更复杂。

所有这些指标都可以使用 Constyble 进行代码检查，Constyble 是 Project Wallace 在其工具集中使用的 CSS 复杂度代码检查器。在为指标定义基线后，只需安装 Constyble 并设置配置文件即可。以下是我直接从 Constyble 自述文件中提取的配置文件示例：

<code>{
  // 不要超过 4095 个选择器，否则 IE9 将删除任何后续规则
  "selectors.total": 4095,
  // 我们不需要 ID 选择器
  "selectors.id.total": 0,
  // 如果出现除这些颜色之外的任何其他颜色，则报告错误！
  "values.colors.unique": ["#fff", "#000"]
}</code>

最棒的是，Constyble 在您的最终 CSS 上运行，因此它只在您来自 Sass、Less、PostCSS 或您使用的任何其他预处理器的所有预处理工作之后才执行其操作。这样，我们可以对选择器的总数或平均选择器复杂度进行智能检查——就像任何代码检查器一样，您可以将其作为构建步骤的一部分，如果出现任何问题，您的构建将失败。

使用 Project Wallace 的收获

在使用 Project Wallace 一段时间后，我发现它非常适合跟踪复杂度。虽然它主要用于此目的，但它也是一种查找 CSS 中代码检查器可能找不到的细微错误的好方法，因为它们正在检查预处理的代码。以下是我发现的一些有趣的事情：

• 我已经停止计算冲刺中需要修复网站上颜色不一致的用户故事数量。 已经有几年的项目，以及人员进出公司：这是一个让网站上每个品牌颜色都出错的秘诀。幸运的是，我们实施了 Constyble 和 Project Wallace 以获得利益相关者的认可，因为我们能够证明客户的品牌在新项目中非常准确。Constyble 阻止我们添加不在样式指南中的颜色。
• 我已经在我的前雇主工作的项目中安装了 Project Wallace webhooks。 任何时候向项目添加新的 CSS，它都会将 CSS 发送到 projectwallace.com，并且会在项目的仪表板中立即显示。这使得很容易发现何时向 CSS 添加了特定的选择器或媒体查询。
• 今年早些时候的 CSS-Tricks 重设计意味着复杂性和文件大小的大幅下降。 重设计非常棒，可以进行分析。它使您有机会仔细查看幕后情况，并弄清楚作者如何更改了他们的 CSS。了解哪些部分不适用于站点以及哪些新部分适用，可能会让您了解 CSS 的发展速度。
• 一家位于荷兰的大型国际公司曾经在一个 CSS 文件中拥有超过 4095 个选择器。 我知道他们正在积极发展新兴市场，并且他们必须支持 Internet Explorer 8 。IE9 在 4095 个选择器后停止读取所有 CSS，因此他们的大部分 CSS 并未在旧版 IE 浏览器中应用。我给他们发了一封电子邮件，他们验证了这个问题并立即通过将 CSS 分成两个文件来修复它。
• GitLab 目前使用超过 70 种独特的字体大小。 我很确定他们的排版系统很复杂，但这似乎有点过于雄心勃勃。也许是因为一些第三方 CSS，但这很难判断。
• 在继承其他开发人员的项目时，我会查看 CSS 分析结果，以便了解项目的难点。 他们是否大量使用了 !important？平均规则集大小是否易于理解，或者他们是否在每个规则集中添加了 20 多个声明？平均选择器长度是多少，它们是否难以覆盖？不必诉诸 .complex-selector-override\[class\][class][class]...[class] 将是很好的。
• 检查缩小是否有效的巧妙技巧是让 Constyble 检查代码行数指标是否不大于 1。 CSS 缩小意味着所有 CSS 都放在一行上，因此代码行数应等于 1！
• 我的另一个项目中一直发生的事情是缩小失败了。 我不知道，直到 Project Wallace 的差异显示给我许多颜色突然像 #aaaaaa 而不是 #aaa 一样被编写出来。这本身并不是一件坏事，但它同时发生在如此多的颜色上，以至于肯定有什么地方出了问题。快速调查显示我在缩小中犯了一个错误。
• StackOverflow 有四种独特的编写白色颜色方式。 这不一定是坏事，但这可能是 CSS 缩小程序损坏或设计系统不一致的迹象。
• Facebook.com 在他们的 CSS 中有超过 650 种独特的颜色。 损坏的设计系统也开始听起来像是一种可能性。
• 我前雇主的一个项目 显示 input[type=checkbox]:checked .label input[type=radio] label:focus:after 是最复杂的选择器。仔细检查后，我们发现此选择器定位嵌套在另一个输入中的输入。这在 HTML 中是不可能的，我们认为我们一定忘记了 CSS 中的逗号。没有代码检查器警告我们这一点。
• CSS 预处理器中的嵌套很酷，但可能会导致错误的事情，例如 @media (max-width: 670px) 和 (max-width: 670px)，正如我在 Syntax.fm 中发现的那样。

对于 Project Wallace 来说，这只是冰山一角。一旦您开始分析您的 CSS，还有更多的东西需要学习和发现。不要只查看您自己的统计数据，还要查看其他人正在做什么。

我已经将我的 Constyble 配置用作与经验较少的开发人员进行对话的谈资，以解释为什么他们在复杂的 CSS 块上构建失败。与其他开发人员讨论为什么我们要避免或推广某些 CSS 编写方式有助于知识转移。它也帮助我脚踏实地。不得不向只想帮忙的 PHP 开发人员解释我已经做了多年的事情，让我重新思考为什么我要按照自己的方式做事。

我的目标不是告诉任何人 CSS 中什么正确或什么错误，而是创建工具，以便您可以验证什么对您和您的同事有效。Project Wallace 在这里帮助我们理解我们编写的 CSS。

以上是寻找可以监视CSS质量和复杂性的堆栈的详细内容。更多信息请关注PHP中文网其他相关文章！