菜单

代码静态品质检查

2019年11月22日 - 银河官方网站
代码静态品质检查

CSS 代码静态质量检查

2015/08/01 · CSS ·
质量检查

原文出处: 百度EFE – ielgnaw   

关于代码静态质量检查,在大佛的上一篇文章 《JavaScript
代码静态质量检查》中已经说得很明白了,虽然主要讲的是
JavaScript 方面,但代码静态质量检查的本质是不变的,今天我们来介绍一下
CSS 方面的静态质量检查。

CSS 中也有一些 Lint
工具,例如 CSSLint,PrettyCSS,recess,CKStyle,stylelint,当然还有百度
EFE 出品的 CSS
代码风格检查工具 CSSHint。本文将从功能、性能、适用范围、规则实现、个性化几个方面对这几个
Lint 工具进行对比。

使用 stylelint检查CSS_StyleLint,stylelint

当你书写大量的CSS代码时,可能会出现不止一个的错误。可能需要某个工具来阻止你CSS书写的错误。

可能,有的时候你的错误真的是一个bug。也有可能仅仅因为草率造成的不一致或者不明确的代码风格。可能它们当中的许多看起来微不足道(取决于你的性子),但是随着代码库的增多以及时间累积,许多人使用时就会做出有丑陋的东西。事情的后果不是你可以想象的。

你尝试去控制自己。你的同事也帮助你,当你游离及时纠正你的错误。但是,你和你的同事都是错误的制造者,所以最后至少在一定程度上都不可避免的失败了。后来,你或者其他人就要解决你页面CSS错误造成的问题。

无论是你或者你同事都不喜欢讨论你犯下的错误,因为这是令人尴尬的事情。甚至有时会令人沮丧或者产生情感破裂。一定的规范有时候对于代码库的维护是有帮助的,如一致的书写风格,可能当手动执行时,看起来有点迂腐乏味。不然它们就会将你平时喜欢的爱出风头,固执的元素展现出来。

另外你可能更喜欢可以及时修正错误,而不是等待代码审查后由别人指出错误后,自己进行修改并声明自己不会再出现此类错误。当你的CSS出现错误时,一个及时的反馈会帮助你节省很多时间。

你所需要的是一个防止错误产生的机器

你需要一个防止错误产生的机器,可以理解CSS并且理解你:你的意图、喜好、主意以及弱点。

这种机器将具有局限性。所有的事物都不是完美的。但是这种局限和你以及你的同事又有所不同。只要是它可以阻止的错误它都会持续阻止,孜孜不倦。同时,你和你的同事可以一直改善机器,扩展它的功能并且削弱其局限性。它是开源的,全世界的人都可以加入其中尽自己的一份力量–其他想要阻止自己出现CSS书写错误的作者。

和其他一样,CSS 作者也需要 linters

我们将这些防止错误出现的程序称为”linters”。Javascript中有几个比较好的linter。尤其是ESLint,它起到的作用如奇迹般,向我们展示了一个好的linter是如此的有用。但是在CSS中,我们就没有这么幸运了,我们的选择十分有限:
基于Ruby的,具有特殊预处理程序的scss-lint和较早的CSS Lint。

但是这都是在PostCSS出现之前。除此之外,PostCSS提供了一些方法,建立更具有良好交互性的CSS工具。它可以将任何类CSS语法解析为抽象语法树(AST)的插件,从而进行分析以及操作。并且利用自定义解析器,PostCSS甚至可以处理不规范的无效模式(如//注释)

成熟的条件已经可以产生一个具有更强大功能的linter —
基于PostCSS的强大功能以及在scss-lint和ESLint最佳功能的启发之下。

我和几个小伙伴一起致力于这个项目,现在我就要开始介绍一下我们开发的工具:
stylelint.

使用stylelint你可以做的事情

以下是尝试于stylelint的功能总结,其中规则多达百余条,并且具有可扩展性。

在这一点,如果你发现自己已经变得有点不耐烦(“Ok,Ok:我相信stylelint将具有奇迹般的工作效果。不需要过多的总结。”)。仅仅跳到下一部分,在这里我仅仅说明一些问题并提供一些提示。

错误捕获

有些stylelint规则旨在找出明显的错误,如拼写错误或者由于你的心烦意乱或者睡眼惺忪时制造的疏漏。例如,你可以禁止空白块,无效的十六进制值,重复的选择器,未命名的动画名称和错误的线性渐变的语法。

其它的规则都是尽自己最大的努力捕捉更细微的错误。这里有一条规则:
当你使用可以覆盖其属性同行(如 margin-top)的速记属性时(如
margin),就会发出警告,因为这可能是由于你的疏忽造成的。另外,还有一种规则会警告你:当出现混乱局面时,如规则A出现在规则B之前,但是实际上覆盖了规则B,因为规则A的的选择器具有更高的优先级(如,规则A为
.foo.bar{···},规则B为 .foo{···})。这是一种十分棘手的情况。

还有一种规则使用了PostCSS的doiuse插件,用于检查你的浏览器是否支持此样式。另外一种则使用了css-colorguard插件用于提示颜色的相似性,以免造成你的混乱使用。(请注意:
这是基于PostCSS之上的stylelint的主要优势之一:相比于其它PostCSS
插件,用很少的努力,stylelint就可以进行提示。)

强制执行最佳实践

如果你在样式表中使用了系统方法,或者对你的代码设置了一个样式指南,你应该取缔这些模式了。stylelint已经提供了这些功能。

首先,你需要狠狠地控制你的选择器。使用stylelint,你可以禁止超过一定特异性的选择器或者在嵌套深度上设置限制。你可以禁止类别选择器(例如没有
id的选择器),并对其余的选择器使用正则表达式进行命名约定。

你可以禁止!important的使用,或者你的浏览器并不支持的brower
hacks。如果你使用Autoprefixer(或者说你应该使用),你可以禁止在源样式表中使用供应商前缀。

如果你想要更加严谨 — 你可以花费一些时间在配置上,以保证绝对的一致性 —
你可以强制执行样式表属性的顺序,并为黑名单,白名单提供属性,值,函数还有单位。

执行代码样式的约定

stylelint具有自动执行代码样式的约定,所以你和你的队友无需主动设置。我们致力于使这些规则更加全面灵活。

这些规则主要针对于空格,但是同样针对于其它的细节,如;引号,大小写字母,在小数前写零,使用关键字以及拼读出值等等。

梦想你和你的队友可以建立一个格式约定(例如我们始终在声明冒号之后留有一个空格),并在你的stylelint配置中进行修改,之后你们就不会为此再次讨论。让其执行于机器王国。

制定以及扩展一切

Nicholas Zakas,ESLint(以及 CSS
Lint)的创作者,写到ESLint的成功在于它的扩展性。stylelint试图遵循ESLint的领先优势,并且提供给CSS
作者一个linter,同样具有扩展性。

你可以书写并且发布自己的规则插件。现在已经具有了一大堆可以使用的;并且我们渴望看到别人的优秀插件。

配置是可扩展的,因此可以共享。至于插件,我们从ESLint了解了这一功能的价值性。检查其中包括WordPress和SUITCSS配置的,并且已经公布的。

如果你不喜欢 stylelint
的内置提示,你可以手工创建属于你自己的风格,甚至可以为你的组织进行创建。你还可以自定义用于提供警告信息的规则。

使用stylelint的API,你可以创建文本编译器的插件,并进行测试使stylelint
融入到你的工作流的每个方面。

如果你有关于stylelint扩展的想法,请让我们知道!

预期问题的答案

在你的心中可能存在几个疑问。这里有几个最为常见问题的解释:

是否可以在SCSS或者Less中使用stylelint?

答案是肯定的,你可以在SCSS中使用stylelint,并且在Less中也得到了支持!自从PostCSS允许自定义解析器,stylelint可以很轻松的支持各种各样的非标准语法

正因为PostCSS解析器 —
因此stylelint支持SCSS,Less以及新SugarSS。如果你想要实现另外一个自定义语法的支持,你可以通过PostLess得以实现!

当然,还有一定的规则在你的非标准语法面前得到羁绊(如迷惑于Sass id选择器的
#{$interpolation})。因为stylelint试图掩盖我们样式表的样式 –

CSSLint

CSSLint 和它底层所使用的解析器 parserlib 都是 Nicholas
C.
Zakas 的作品(当然,ESLint 也是他的作品)。它适用于浏览器以及
CLI 环境,在浏览器端和 CLI
环境中分别是两套代码,这么做的原因是它的底层库 parserlib 在浏览器和
CLI 环境分别是两套。

功能上,CSSLint 提供了对 CSS
的解析、检查等功能。在规则实现方面,无法通过 JSON
配置来管理,默认的规则全部在src/rules/ 目录中,要添加自定义规则,必须通过全局的 CSSLint.addRule 方法来实现。

实现上,CSSLint 主要是利用事件监听,在底层 parse CSS
过程中触发事件,例如startstylesheetendstylesheetcharsetimportnamespacestartmediaendmediastartpageendpagestartrul 和endrule 等,事件回调中会返回当前
AST 的信息,开发者根据这些信息来进行规则检测。

性能上,如果不添加自定义的规则,性能还是不错的,但是一旦添加自定义规则,性能就会打些折扣。这是底层解析器 parserlib 的原因,parserlib 功能比较单一,而且返回的
AST
上信息不是很丰富,也不支持插件机制,因此要实现一些自定义的规则,基本只能靠正则匹配来实现。

CSSLint 开发时间比较早,同时也因为大神的影响力,因此现在周边配套非常丰富,支持各种编辑器例如:TextmateSublime TextAtomVimEmacs 等等。

一些人使用标准CSS,一些人使用扩展语言如SCSS,一些人使用一些怪异的自定义属性等等

这些难免都会产生一些漏洞需要去填补。但是,我们一直在处理我们找到的这些错误;在此期间的任何规则可以完全被关闭或者逐次样式表或者逐次行的进行禁用。

stylelint是否可以使用未来CSS语法?

是的!类似于上面所述的答案:
stylelint可以理解PostCSS所理解的任何东西,包括启用未来任何的CSS语法(可能通过PostCSS插件)。事实上,一些stylelint规则专门处理未来CSS语法和一些自定义属性。

stylelint配置是巨大的,我应该从哪儿开始呢?

我们建议三种配置方式:

扩展一个发布的配置。我们维持stylelint-配置标准,以便于为用户提供一个固有的基准。并且许多的配置也已经公布。从头开始,一次添加一条规则。默认情况下,没有一条规则被开启,所以通过手动添加规则你就会知道哪一个会被强制执行,并且可以理解你添加的每条规则。启动复制粘贴配置,决定使用哪些选项并选择性进行删除。

值得庆幸的是,你不需要一遍又一遍的书写巨大的stylelint配置。你可以选择一个你喜欢的风格并且可以在任何地方使用它。

运行stylelint最简单的方式?

对于大多数人而言,最简单的方式就是通过它的命令行。

如果你更偏爱gulp插件,你可以使用gulp-stylelint。对于webpack,这里有很多选择的可能性。我们希望这些插件可以激励你们创建其它的stylelint插件,例如,适用于Grunt的插件。(你可以在开源项目中去寻找!)

你也可以使用PostCSS
插件运行stylelint,包括插件中所包含的任何东西。这就意味着你可以在任何可以使用PostCSS(几乎涵盖于每一个编译工具)的地方使用stylelint!

此外,这里也存在一个适用于Atom,Sublime Text,VS
Code的stylelint文本编译插件,以提供最快的反馈。关于更多信息,请查阅
stylelint 网站上的互补工具列表。

如下所示,在命令行中,你所期待看到的结果:

图片 1

在Atom中显示如下;

图片 2

stylelint是否可以修补我的错误?

不,但是另外一个叫做stylefmt旨在做到这一点。它需要一个stylelint配置 –
十分类似于你在linting使用的 –
并且可以修复任何错误。我们希望随着社区人员的贡献,stylelint可以发展到自动修补违反stylelint规则的错误。请帮他们实现这个目标!

你也可以使用其它的工具,例如CSScomb或者与stylelint联合使用的perfectionlist,自动修复并自动强制休息。

使用linting进行约束补充

在良好的CSS中有巨大数额的约束。这就是为什么我们花费大量的时间讨论
SMACSS, ACSS, BEM, SUITCSS,
ITCSS等等的方法。我们都知道书写糟糕的CSS是十分容易的,所以,如果让我们不再畏惧于CSS样式的书写,我们需要在工作中建立一个智能化的战略并勇敢的坚守下去。

stylelint的目标是自动执行 —— 提供一套核心规则和一个可插拔的框架以便于CSS
作者可以使用来执行自己的战略。

试一试,让我们知道如何为你提供服务。如果你有相关更好的改进想法,如贡献规则、
增强功能、 测试、 修复bug、 文件、
新想法或只是反馈,请给我们提出!这样我们所有级别的开发人员就有工作做了。

stylelint检查CSS_StyleLint,stylelint
当你书写大量的CSS代码时,可能会出现不止一个的错误。可能需要某个工具来阻止你CSS书写的错误。…

PrettyCSS

PrettyCSS 是一个比较出色的 Lint 工具,但它并不算是一个纯粹的
Linter,更应该把它称作一个 Parser,这也是它出色的原因。在 Parser
里面实现的 Linter 以及 Pretty,这样可以最大程度的保证 Linter
的精确度。它适用于浏览器端、作为 Node.js 模块以及 CLI 工具。

实现上来说,在 Parser 中集成 Linter 即在 Parse 阶段就把 Linter
的规则给检测了,因此性能较好。当然缺点也比较明显,就是无法自定义规则。

如果 PrettyCSS 未来能够提供插件机制,允许自定义规则,会更有吸引力。

recess

Twitter 出品的 CSS 代码质量检查工具,可以作为 Node.js 模块和 CLI
工具来使用,不知道是什么原因,master 分支已经两年没有维护了,v2.0.0
分支也有将近半年没有更新了。

比较有特点的是,recess 没有用任何 CSS 解析器,而是直接用 Less
解析器来做的,因此也就默认了一个编译 Less
的功能,但其他方面的功能就比较弱了,可能是时间比较早的原因吧。所有默认规则都在 lib/lint/ 目录下,没有插件机制,无法扩展。

实现上,结合 Less parse 出来的 AST
进行规则分析检查,性能上表现一般,因为 Less parse
后还会有 toCSS 这么一步,本质上就会比纯 CSS
解析器要多一个步骤。在规则的实现程度上也比较一般,只实现了个规则,这可能也是因为底层是
Less 解析器的原因。

就目前来看,v2.0.0 相对于 master
来说并没有改动太多,整体结构没有变化,底层还是使用 Less
解析器,区别仅仅是增加了一个data-uri 的规则以及修改了一些
codestyle。

CKStyle

CKStyle 是国产的 CSS
代码检查工具,定位是一脉相承的 CSS 检查、美化、修复、压缩工具。适用范围包括在浏览器端使用、作为
Node.js 模块以及 CLI 工具。这个工具最开始是 python
版本的,大约一年前改成
Node.js 版本了。这个版本和之前的 python
版本比较起来,增加了一些默认的规则实现以及提供了浏览器端的支持。

CKStyle 在功能上还是比较丰富的,它提供了对 CSS 的解析、检查、fix
和压缩。但是它同样无法通过配置文件来管理规则,默认的规则全部在 ckstyle/plugins/ 目录中,要添加自定义规则,只能在全局 global 上挂载一个 RuleChecker 的子类。

实现上,CKStyle 直接解析 CSS 文件,然后结合返回的 AST
对象做一些规则的检测。性能比较不错,这是因为底层 CSS
解析器是自己根据默认的规则来定制的,很少有正则上的一些匹配。这就好像是坑是自己挖的,那么自己总能想到一个简单快速的方法把坑填满一样。

CKStyle 整体规模上看起来比较大,但是不知道什么原因,并没有在社区流行。亮点是功能很丰富,检查、美化、修复和压缩全都有,甚至提供了一个服务 CKService,帮助检查网站的
CSS。

stylelint

stylelint 本质上和下面将要介绍的 CSSHint 是一样的,都是基于 postcss 解析器实现的,除了规则实现的数量不一样,最大的区别就是 stylelint 是用
ES6 写的。所以这里就不介绍了,直接看下面的 CSSHint 了。

CSSHint

CSSHint 是百度 EFE 出品的 CSS 代码风格检查工具,在 2014
年底应公司内部全面推行代码规范检查的需求而产生的。目前CSSHint 支持
Node.js 模块以及 CLI 方式使用,提供对 CSS 的解析和检查等功能,通过 JSON
文件来管理规则的配置。

在项目刚开始设计阶段,我们曾考虑使用大神的 CSSLint,但在经过调研后发现,CSSLint 在针对我们自己的规范做规则检测的时候,发现一些问题:首先 CSSLint 默认实现的规则里面并不能完全覆盖我们自己的规范,其次,在单条规则上,对规则匹配度也不够,最后,基于 CSSLint 来写插件不太方便。因此,我们决定基于 CSSLint 解析器 parserlib 重新实现一套
CSS
代码检查工具。这就是 0.1.0 版本之前的 CSSHint,经过一段时间的使用我们发现这个解析器返回的
AST
上信息太少,而且针对解析器来写插件也不方便。因此在 0.1.0 版本的重构中,我们把底层解析器换成了 postcss(postcss 和 parserlib 相比,最大的优点是优秀的插件机制,而且
AST
上的信息也更完整),同时改变了实现的方式,在性能和功能上较 0.1.0 之前版本有较大的提升。

得益于 postcss 优秀的插件机制,CSSHint 提供了较为丰富的规则实现,每个规则实际上就是一个 postcss 的插件,扩展新规则比较方便,只需注册到 postcss.plugin 上即可。

在实现上,也是直接解析 CSS
文件,然后在每个插件里面调用 node.eachRule 或者 rule.eachDecl 来实现对选择器或者属性的遍历,回调函数中返回的是
AST,然后根据这些信息做规则的检测。同时针对我们的需求,CSSHint 提供了行内注释的方式来动态的配置规则。

CSSHint 目前还不支持浏览器端使用,相对于 CKStyle 的大而全,CSSHint 更加专注于
Lint
本身。覆盖更多的规则(包括CSSLint的规则)、提供更易用扩展方式、提供更加灵活的行内注释指令匹配方式(开启、关闭、嵌套)等功能才是 CSSHint 的专注方向。

总结

CSSLint 中规中矩,各个方面比较均衡,如果你是大神Nicholas C.
Zakas
的粉丝,那么 CSSLint 是你的必选项。

PrettyCSS 性能比较好,如果 PrettyCSS 默认实现的规则可以满足你并且你不会有自定义规则的需求的话,那么 PrettyCSS 就是你的不二之选。

recess 虽然师出名门,但是维护跟不上,在功能上已经不能满足如今的需求了,只能当做代码学习来使用了。

CKStyle 功能丰富,但是精细程度不是太高,如果你要求不太高,对功能的丰富程度更加在意,那么推荐使用 CKStyle,而且是国人出品,中文文档,看起来也比较方便。

stylelint 本质上和 CSSHint 一样,可以作为一个 ES6 的学习项目。

CSSHint 已经发布了 0.2.0 版本,在扩展性、规则的自定义上表现不错,同时,除了满足我们自己的规范,还覆盖了 CSSLint的规则。目前来看,CSSHint 是覆盖规则最全的一个
CSS
代码风格检查工具了,而且扩展起来也比较方便,另外,行内注释指令的功能在其他
Lint 工具上也是没有的,个人来看,未来的潜力比较大。

1 赞 1 收藏
评论

图片 3

相关文章

发表评论

电子邮件地址不会被公开。 必填项已用*标注

网站地图xml地图