强制执行 CSS 语法风格（以及更多！）

我敢打赌，您在编写 CSS 时大多都有一定的风格。比如，您喜欢使用 4 个空格缩进。您总是在花括号和冒号后加一个空格。您总是在规则集后加一个空格。您只在一行上放置一个声明，并且唯一可以多行的声明是像渐变或逗号分隔的 box-shadow 这样的大型代码块。

您可能会更进一步，将此风格规范化。也许您会就此召开团队会议，并决定您希望如何设置代码风格。您会编写一份指南，并让团队中的每个人都能看到它。

您可能会说，整洁的代码很重要。虽然代码中的风格差异实际上并不影响最终输出（我们大多数人都有压缩代码的构建流程），但它对日常工作很重要。杂乱且不一致的代码库难以查看和理解。跳入整洁的代码可以更快地进入正确的思维状态，并开始解决手头的难题，而不是浪费时间因代码混乱而感到沮丧。

Harry Roberts 最近甚至称之为 开发人员的试金石

【整洁的代码】似乎是一件非常肤浅的事情，但在我看来，整洁的代码暗示着更重要的事情：我会假设一个整洁的开发者对细节更关注，更有可能遵循流程，更有可能发现错误。无论对错与否，我将其视为更普遍的方法和态度的试金石。

自动代码风格检查/警告

除了达成标准之外，还可以让您的计算机帮助您确保自己做对了。

我敢打赌，对于 JavaScript 或服务器端语言程序员来说，这是一种更为常见的事情。例如，ESLint 非常流行。您可以根据团队决定的良好语法配置它，并使用 大量的规则。

ESLint 比代码风格检查更进一步，例如，它知道您是否使用了某个函数，或者尝试使用未定义的变量。像 Rubocop 这样的 Ruby 代码工具也类似。您可以将其用于代码风格检查，但也可以做更多的事情。

代码风格检查不必在代码编辑器本身中进行。如果在代码编辑器中进行，则非常有用，这样您就可以在编写时立即修复问题，但它不必在代码编辑器中进行。对于一个庞大且技术多样化的团队来说，将代码风格检查作为任务运行/构建流程设置的一部分可能更实用。

例如，ESlint 可以集成到 Grunt 或 Gulp 中，因此在处理 JavaScript 文件时，您会看到错误输出。

因此，有多种方法可以整合代码风格检查

• 在本地 IDE 中
• 作为本地任务运行程序设置的一部分
• 作为自动化测试的一部分
• 这些方法的某种组合

并且您可以更进一步。例如，将代码风格检查错误视为测试失败，并阻止 git 工作流程。例如，在所有检查都通过之前，您无法完成合并请求。

等等！我们这里说的是 CSS！

确实。据我所知，stylelint 是这里的主要参与者。David Clark 去年在 CSS-Tricks 上写了关于它的所有内容。

stylelint 非常类似于 ESlint。您可以以相同的方式将其整合：例如，作为任务运行程序工作流的一部分，或直接在您的代码编辑器中。

目前我正在使用 Sublime Text，这里我使用 stylelint 和 SublimeLinter，这与我用于 ESlint 的完全相同的 linter UI。

您可能也会从 标准配置 开始。

关于有主见的 CSS 选择？

您可以说 stylelint（和 ESlint）是没有主见的。它们有意设计得非常灵活。您可以整合任何您想要的规则（或省略规则），即使添加规则，它们也旨在通过以一种或另一种方式强制执行规则甚至允许例外来保持灵活。

更重要的是，我称它们为没有主见的，因为它们并不是真正地对您的代码进行评判。但是，如果您希望有一个工具来对您的代码进行评判呢？

“嘿，您使用了太多的浮动！”

“嘿，该属性的兼容性不是很好！”

“嘿，@import 对性能影响很大！”

那更像是 CSSLint 的领域，它有各种各样的 相当有主见的规则。

当然有一些重叠。例如，CSSLint 可以检查重复的属性，就像 stylelint 可以检查一样。

您可以将它们一起使用吗？可能可以。当然，在命令行/任务运行程序级别，您可以这样做。我不完全确定如何同时将它们都集成到 IDE linter 中。试试看！

也许一个比较有助于总结这部分内容

• stylelint 非常类似于 ESlint（不太有主见）
• CSSLint 非常类似于 JSlint（更有主见）

这些东西不能真正地自动化吗？比如真正地帮我解决问题？

这正是我最初思考这些问题的原因。我非常喜欢 IDE 级别的代码风格检查，但我认为我更喜欢自动修复代码风格的想法。

我们在这里实际上是在谈论“美化”（也称为“代码整理”或“美化”）。

JavaScript 中新的超级流行的工具是 Prettier，我认为这是一个不错的选择。但这对我们处理 CSS 没有帮助。

还有一个工具，JS Beautifier，它确实可以处理 CSS（和 HTML！）

CSS Comb 是另一个非常适合这个领域的工具。它提供的选项远少于 stylelint（您认为这是好是坏），并且有一个 很酷的配置构建器 用于设置这些规则。CSS Comb 看起来非常流行且功能完善，但我不会进一步推荐它，因为它看起来开发人员已经不再维护该项目了。

该工具不再开发，尽管我们可能会修复解析错误和严重错误。这意味着您不应该期望任何新功能或选项。

CSS 如今变化很快，因此我担心整合一个不会更新的工具。有点可惜，因为 CSS Comb 可以做一些其他工具无法做到的事情，比如根据您的意愿重新排序属性，这很酷（尽管与往常一样，有 选项）。

可能存在比这两个工具更好的选择……

stylefmt

既然 CSS 代码风格检查的最佳选择是 stylelint，为什么不使用完全相同的 stylelint 配置来实际修复 CSS 呢！（好吧，几乎完全相同。）

stylefmt 就是这么做的。并且，与我们讨论过的其他大多数工具一样，它可以集成到按需的 IDE 级别，或者作为任务运行程序/构建流程的一部分。

这是我在 Sublime Text 中使用 SCSS 文件的示例，该文件存在 stylelint 错误，并通过 stylefmt 修复了这些错误。

不错。

stylefmt 不是唯一的选择，还有 perfectionist。

总结

样式检查非常酷。它不仅可以实现，还可以根据您的喜好进行高度自定义。您可以将其整合到最适合您和您的团队的流程中的任何位置。对于 CSS，使用stylelint 会是一个不错的选择。您甚至可以使用像stylefmt 这样的工具自动修复问题。您还可以获得对整个代码库相当不错的覆盖范围，例如使用ESlint 用于 JavaScript 和Rubocop 用于 Ruby。