前端代码规范（静态检查）工具

浅浅的花香味﹌ 2022-08-23 04:54 374阅读 0赞

# 一、CSS代码规范处理工具 #

*  CSSLint
 *  PrettyCSS
 *  recess
 *  ckstyle
 *  stylelint
 *  CSSHint

## 1.1CSSLint ##

官网：[http://csslint.net][http_csslint.net]

### 概述 ###

CSSLint是一个用来帮你在线上分析并检测找出CSS代码中问题的工具，它可做**基本的语法检查**以及使用一套**预设的规则**来检查代码中的问题，**规则是可以扩展的**。

### 使用方法 ###

使用方法很简单，只需要把 CSS 内容复制贴上，最后按下 LINT！按钮就可以检查。底下有一些设定项目可以调整检测的项目和规则，预设是全部勾取，如果没有特别的需求可以不用更动，完成之后 CSS Lint 会告诉使用者该样式表哪些部分发生问题，只要依照网站的指示修改就可以得到比较没有问题的 CSS 样式表啰！

### 一些规则 ###

**1. 修复解析错误**（Parsing errors should be fixed）  
**2. 避免使用多类选择符**（Don’t use adjoining classes）  
IE6以及更古老的浏览器对类似.foo.bar的多类选择符解析不正确，参考IE6下的多类选择符一文。  
**3. 移除空的css规则**（Remove empty rules）  
这个规则不包含任何属性，类似：

.foo { }

空规则的产生原因一般来说是为了预留样式。去除这些空规则无疑能减少css文档体积。

**4. 正确使用display的属性**（Use correct properties for a display）  
由于display的作用，某些样式组合会无效，徒增样式体积的同时也影响解析性能。CSS Lint会检查一下几点：

display:inline后不应该再使用width、height、margin、padding以及float。
    display:inline-block后不应该再使用float。
    display:block后不应该再使用vertical-align。
    display:table-*后不应该再使用margin或者float。

**5. 不滥用浮动**（Don’t use too many floats）\*  
虽然浮动不可避免，但不可否认很多css bug是由于浮动而引起。CSS Lint一旦检测出样式文件中有**超过10次的浮动便会提示警告**。

**6. 不滥用web字体**（Don’t use too many web fonts）  
对于中文网站来说Web Fonts可能很陌生，国外却很流行。web fonts通常体积庞大，而且一些浏览器在下载web fonts时会阻塞页面渲染损伤性能。

**7.不声明过多的font-size**（Don’t use too may font-size declarations）  
这是设计层面的问题，设计精良的页面不会有过多的font-size声明。

**8. 不在选择符中使用ID标识符**（Don’t use IDs in selectors）  
主要考虑到样式重用性以及与页面的耦合性。

**9. 不给h1~h6元素定义过多的样式**（Don’t qualify headings）  
**10. 全站统一定义一遍heading元素**(Heading styles should only be defined once）  
若需额外定制样式，可使用其他选择符作为代替。  
**11. 值为0时不需要任何单位**（Zero values don’t need units）  
**12. 标准化各种浏览器前缀**（Vendor prefixed properties should also have the standard）  
通常将浏览器前缀置于前面，将标准样式属性置于最后，类似：

.foo { -moz-border-radius: 5px;border-radius: 5px; }

**13. 使用CSS渐变等高级特性，需指定所有浏览器的前缀**（CSS gradients require all browser prefixes）  
**14. 避免让选择符看起来像正则表达式**（Avoid selectors that look like regular expressions）  
css3添加了一些类似~=等复杂属性，也不是所有浏览器都支持，需谨慎使用。  
**15. 遵守盒模型规则**（Beware of broken box models）

上述某些规则也许不是最佳实践，可根据项目需求自行添加修改，这也符合CSS Lint pluggable的宗旨

### 优缺点 ###

优点：

1.规则可以自定义

缺点：

1.在线，需要网络

2.点了Lint按钮没有反应

# JS代码规范工具 #

*  JSLint
 *  JSHint
 *  ClosureLinter
 *  JSCS
 *  ESLint
 *  YUI Compressor
 *  UglifyJS

当写js代码的时候，一个校验工具可以帮助我避免愚蠢的错误。尽管我有许多年的经验，但是我仍然有变量命名不正确、产生语法错误以及忘记正确处理错 误。在我浪费时间，尤其是客户时间之前，一个好的校验工具或校验器可以告诉我这些问题。好的校验工具可以确保一个项目遵循代码规范。

存在五个可以使用的js校验器，但是怎么选择使用哪一个呢？接下来让我们看看这五种种流行方案的特点、优点和不足：**JSLint**、**JSHint**、**JSCS**、**ESLint**、**UglifyJS**。

五种工具用相同的基本方式工作。他们都有一套用户分析、报告js文件错误的规则。他们都可以通过npm安装。他们都可以通过命令行使用、作为Grunt插件使用、也可以集成到编辑器中。他们五种均支持使用注释进行配置。

但是相似点结束了。每个工具都有各自的优点和缺点–优点是通过比较得到的。

## JSLint ##

JSLint是其中最老的工具。在2002年 Douglas Crockford开发了该工具，根据其经验，强制使用js语言中精粹的部分。如果你同意这些精粹，JSLint能成为一个好的工具。

JSLint的缺点是不能配置和拓展。你根本不能禁掉需要特性，并且很多缺少文档。官方文档非常不友好，例如缺少如何将其集成到编辑的信息。

优点

参数配置完成，可以直接使用

缺点

JSLint不存在配置文件，如果想改变参数设置，那就存在问题

有限的配置选项，许多规则不能禁掉

不能增加个性化规则

没有文档记录规则

很难弄清楚哪个规则引起的错误

## JSHint ##

作为一个可配置的JSLint版本，JSHint被开发出来。你可以配置每个规则，将其放到一个配置文件中，这样在大项目中可以容易使用。JSHint对每个规则有好的文档，所以可以准确知道每个规则的作用。将其集成到编辑器也是简单的。

JSHint的一个小缺点是里面的松散默认配置。也即是你在使其可用之前必须将其启动。和ESLint相比，确定哪个规则用户开启或关闭错误信息，JSHint是更加困难。

优点

大多是参数可以配置

支持配置文件，在大项目中容易使用

已经支持需要类库，像jQuery、QUnit、NodeJS、Mocha等

支持基本的ES6

缺点

难于知道哪个规则产生错误

存在两类选项：强制选项和松散选项。使得配置有些混乱

不支持自定义规则

## JSCS ##

JSCS不同于其他，因为如果不给它一个配置文件或告诉它一个配置项，JSCS不会做任何事情。可以存他们的网站现在配置项，所以这不是个大问题，并且有许多配置项，例如jQuery代码风格配置项、Google配置项。

它有超过90个不同的规则，通过插件可以创建自定义规则。当和其他工具集成需要特定格式时，JSCS也支持自定义报告使得变得非常容易。

JSCS是一个代码风格检查器。这意味着它仅仅匹配代码格式的问题，不匹配潜在的bugs、errors。因此，跟其他工具相比缺少灵活性，但是如果你仅仅强制检查代码风格，JSCS也是一个好的工具。

优点

支持自定义报告，更容易与其他工具集成

如果你遵循一种可用的代码风格，配置项和准备好的配置文件使其容易启动

在报告中存在标记包含规则名字，所以很容易指出哪个规则造成了错误

通过自定义插件进行拓展

缺点

仅仅检查代码风格的问题。JSCS不检查潜在存在的bugs，例如不适用的变量、偶然的全局变量等等

四个工具中最慢，但是在使用中不是一个问题

## ESLint ##

ESLint是最新出来的工具。它被设计的容易拓展、拥有大量的自定义规则、容易的通过插件来安装。它给出准确的输出，而且包括规则名，这样可以知道哪个规则造成了错误。

ESLint文档多少有些混乱。规则容易查找，以及被分为逻辑组，但是配置指南在有些地方容易弄混。然而它可以在一个地方提供链接去编辑集成、插件和样例。

优点

灵活，任何规则都可以开启闭合，以及有些规则有些额外配置

很容易拓展和有需要可用插件

容易理解产出

包含了在其他检查器中不可用的规则，使得ESLint在错误检查上更有用

支持ES6，唯一支持JSX的工具

支持自定义报告

缺点

需要一些配置

速度慢，但不是主要问题

## UglifyJS ##

UglifyJS是基于 NodeJS 的Javascript语法解析/压缩/格式化工具

官网：[http://lisperator.net/uglifyjs/][http_lisperator.net_uglifyjs]  
安装  
$ npm install uglify-js -g

# 我的推荐 #

我的选择是ESLint。JSHint是严格和不可配置的，而JSHint缺少拓展机制。JSCS如果仅仅用于代码风格检验是一个好的选择，但是ESLint不仅可以进行代码风格的检验，而且可以检查代码中的bug和其他问题。

如果使用ES6，ESLint也是明显的选择。在上面提到的工具中，ESLint对ES6支持的最广泛。

如果你像尝试ESLint，我已经创造了5步快速开始指南。你可以 download the ESLint 5-step quickstart guide form my website

JSHint是第二选择。如果不需要ESLint先进的特点，JSHint一旦配置就可以捕获需要好的问题。带有许多规则的JSCS，如果出了代码风格外不进行其他检查，将是一个好的选择。

我非常犹豫去推荐JSLint。其他工具做同样地事情，但是不强制用户遵守这些规则。唯一的例外是你碰巧统一那些强制规则，那是值得深入研究的情况。

一个检验工具是捕获问题的很好一步，但是仅仅能看到它规则的错误。为了更进一步的bug自动捕获，我推荐使用单元测试。code view也有助于达到该目的。

[http_csslint.net]: http://csslint.net
[http_lisperator.net_uglifyjs]: http://lisperator.net/uglifyjs/

前端代码规范（静态检查）工具

发表评论取消回复

还没有评论，来说两句吧...

相关阅读

相关 10个静态代码检查工具

相关前端代码规范（静态检查）工具

相关在phpstorm上安装代码规范检查工具

相关【编码规范】代码检查工具

相关前端代码检查

相关 IntelliJ 代码规范检查设置

相关前端代码规范

相关阿里代码规范检查工具的安装使用

相关 idea阿里代码规范检查工具的安装使用

相关代码质量静态检查工具