All code in any code-base should look like a single person typed it, no matter how many people contributed. — idiomatic.js

fecs 是以百度前端代码规范为目标的前端代码风格套件，套件包括 htmlcs、csshint、lesslint 和 jformatter，此外还有社区的相关开源模块 cssbeautify、csscomb、fixmyjs 和 esformatter：

显而易见，fecs 不仅能检查 HTML/CSS/LESS/JavaScript 代码的规范问题，而且还能修复代码的规范问题。

代码检查

fecs-check

代码的检查，目前主要是以百度前端代码规范（JS/CSS/HTML） 的检查为首要目标，同时根据 EFE 的技术规划，为 Less 代码规范 的检查带来了 lesslint。

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

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

作为一个前端，不可避免同时与三个语言打交道：JS、CSS 和 HTML。而 HTML，超文本标记语言，是其中可编程性最弱的，一直以来得到的关注都较少。加上浏览器对 HTML 逆天的容错支持，即使是错误百出的文档也可以在浏览器里边表现得中规中矩。这样的背景下，绝大部分被产出的 HTML 代码都存在着各种各样的小问题，比如缺少必要的元信息（meta），比如混乱的 class、id 或属性的取值格式；这些问题或影响页面在不同浏览器下的表现，或增大了页面的开发、维护成本。

因此，选用一个合适的工具对 HTML 代码进行质量控制会是一件很有意义的事情。本文选择了 Bootlint、AriaLinter、htmllint、HTMLHint 及 htmlcs 这五个目前最活跃的相关项目进行对比。除此之外还存在如 tidy、W3C/Mozilla HTML validator 等工具，但它们专注于 HTML 规范，几乎不涉及代码风格上的检查，这里就不做比较。

对比角度将主要包括以下几个方面：

• 使用及配置
• 规则实现及自定义
• 性能
• 亮点

为了后续说明的便利，这里先对语法风格的规则进行简单的分类，第一类包括 attr-value-double-quotes（使用双引号包围属性值）， max-length（限制单行最大长度）， tag-pair（要求需要显式闭合的标签显式闭合）等；第二类包括 script-in-tail（JavaScript 内容要求在页面最后嵌入）, title-required（要求 title 标签）, id-class-ad-disabled（不允许在 id 或 class 的值中出现 ad_，ad-，_ad，-ad 等）等。这两类规则有很明显的区别，第一类偏重于代码格式（遵循与否都不影响最终语义），这里叫它格式规则；对应地，第二类偏重语义，即最终 document 的表现，这里叫它语义规则。一般情况下，前者更适合在语法分析阶段做，而后者更适合在分析完后基于分析结果（AST / document）进行。

自鸿蒙初判，Brendan Eich 10 天捏出 Mocha 之后，即便进化成 ECMAScript，这个语言依旧毁誉相随。那些经过重重劫难，侥幸渡劫成功的苦主标识了诸多天坑（见 JavaScript Garden） —— 当然，你也可以称之 feature。据无责任乱猜，Douglas Crockford 也没少踩坑，于是才有了蝴蝶书《JavaScript: The Good Parts》，下雨天与 JSLint 一起使用会更配哟。

《JavaScript: The Definitive Guide》 V.S. 《JavaScript: The Good Parts》

时至今日，代码的静态质量检查在项目质量保障方面的重要性与必要性已毋庸置疑。越来越多的开发者意识到了这一点，纷纷在项目构建流程或者源码控制系统中添加静态检查的 hook。本文将依时间顺序，选出 JavaScript 史上的主要几个 Linter 作横向比较，最终属意谁家，那就见仁见智了。