1.背景
首先必须承认,静态代码检查不能解决所有问题!比如说,QA不能指望着靠静态代码检查来发现rd的代码逻辑的bug。而对于javascript,可能就是代码某处少了个分号,或者是某些编码的bad –practice。这些问题可能很小很小,但是对用户体验足以造成巨大影响。因此,如果这种检查真的能发现问题,那么还是很有必要的。
之后的一个问题是成本:为了发现一个潜在的问题,我们要付出多少精力?静态检查给我们的印象是:飞速的扫描一遍代码然后返回一大堆信息——就像一个可能蕴藏金子的沙堆,我们必须有耐心才能在这个沙堆中找到有价值的信息。显然这一过程的成本由以下两部分组成:代码扫描+判别有效性。第一个过程往往十分迅速,秒级而已。而第二个过程往往需要人工的介入,这是成本消耗的关键点。试想,如果静态检查返回过多无用信息,导致人工检查耗时过长,则这种检查的收益就得不偿失了。
综上所述,静态代码检查面临的挑战是:准确性和低成本。
2初识静态检查规则与工具
静态检查工具jslint&jshint
为了应对QA前端js知识储备不足的短板,我们除了加强自身的学习之外,一个有效的方法就是“站在巨人的肩膀上”。
1、jslint
前端领域的大牛Douglas Crockford编写了JsLint[3],将他认为的那些重要的js编程实践作为静态检查项,他提出的某些编程实践也确实被人们所接受,因为这确实是容易引起问题的关键点(例如,在应该使用===的地方不要使用==等)。不过JsLint也存在一些问题,如它的某些检查过于严苛;遇到for-in语句后会停止检测;且非开源。。这些问题都使得人们对JSLint“敬而远之”。
2、jshint
为解决jslint现存的问题,有了JSHint这个项目,此开源项目作为JSLint的一个分支,允许用户自定义检查项,使用起来更加轻量级。有了JSHint,程序员就可以根据自己的编程习惯来定制个性化的检查策略。文献[1] 讲述了JSHint与JSLint的区别。
JsHint本质上是一个js库(jshint.js)。笔者也曾膜拜此文件的代码,发现它实际上是一个js的词法分析器,里面定义了各种规则,然后对输入的代码字符串做切词和匹配,每发现一个“错误”(或是坏的编程实践)就放到结果数组中保存起来。因此,如果你会写js代码的话,完全可以在js文件中引用jshint.js。例如,你可以使用JSHINT函数来进行代码检查,如下所示:
var result = JSHINT(source, options);
其中JSHINT是一个全局函数,第一个参数source : 必选项。表示需要检查的代码,js或者json,可以传一个字符串或者一个数组。如果传字符串,需要用’r’或者’n’来分隔一行一行的代码;如果传数组,则每一个数组元素表示一行的代码。第二个参数option : 可选项。表示代码检查的配置项,具体的配置项含义参见文献[2],使用key/value字典表示,key就是要检查的配置项名称,value是bool类型。返回值:如果代码没有问题,JSHINT会返回一个true;否则返回false。当返回值是false的时候可以使用JSHINT.errors获取出错的原因,JSHINT.data包含了本次检查更详细的信息。另外,使用JSHINT.report可以生成错误信息的html报告。
认识检查规则
prop | description |
bitwise | 如果是true,则禁止使用位运算符 |
curly | 如果是true,则要求在if/while的模块时使用TAB结构 |
debug | 如果是true,则允许使用debugger的语句 |
eqeqeq | 如果是true,则要求在所有的比较时使用===和!== |
evil | 如果是true,则允许使用eval方法 |
forin | 如果是true,则不允许for in在没有hasOwnProperty时使用 |
maxerr | 默认是50。 表示多少错误时,jsLint停止分析代码 |
newcap | 如果是true,则构造函数必须大写 |
nopram | 如果是true,则不允许使用arguments.caller和arguments.callee |
nomen | 如果是true,则不允许在名称首部和尾部加下划线 |
onevar | 如果是true,则在一个函数中只能出现一次var |
passfail | 如果是true,则在遇到第一个错误的时候就终止 |
plusplus | 如果是true,则不允许使用++或者- -的操作 |
regexp | 如果是true,则正则中不允许使用.或者[^…] |
undef | 如果是ture,则所有的局部变量必须先声明之后才能使用 |
sub | 如果是true,则允许使用各种写法获取属性(一般使用.来获取一个对象的属性值) |
strict | 如果是true,则需要使用strict的用法, 详见http://ejohn.org/blog/ecmascript-5-strict-mode-json-and-more/ |
white | 如果是true,则需要严格使用空格用法。 |
不足
牛人的东西很好,但实际使用起来发现有如下的问题:
(1)静态代码检查规则配置需要修改Jshint的Js源代码,修改代价较高,且容易出错;
(2)检查结果误报较多,且可读性差,找到真正是问题的结果需要排查几K的报错信息,效率较低。
3.jshunter:一款基于jshint的静态代码检查工具
为解决Jshint以上2个突出问题以及扩展更多的特性满足ECOM WEB类产品JS静态代码检查的准确性、有效性,基于Jshint和Rhino开发了Jshunter这一款工具用于js代码语法类错误检查。
Jshunter提供的解决方案如下:
(1)检查规则灵活配置。Jshunter支持将所有检查项放到一个配置文件中,用户可以通过true或false来自定义个性化的检查项,而不必修改Jshint源代码;
(2)清晰醒目的结果报表。Jshunter从繁杂的检查结果字符串中提出关键信息,以Html文件的形式展现,对扫描结果严重程度给出LEVEL标识。非常适用于持续集成的开发模式,作为Hudson上的一个报表呈现;示意图如下:
(3)支持Html内嵌js代码的检查,提高检查准确性。业界的Jshint不支持Html内嵌Js代码检查,存在漏检、漏测的风险。Jshunter解决了这个问题,不但能检查Js文件,还能检查Html中内嵌的文件;
(4)扫描结果过滤,减少冗余信息,提高结果分析效率。通过黑名单过滤和错误级别设定,Jshunter支持用户设定结果提醒级别,目前支持warning,error和ignore,其中被设定ignore的错误不会在报表中呈现,减少冗余信息的查看与分析。
具体说来,之前困扰的根源就在于我们解析jshint.js的环境是浏览器,受限于浏览器的环境,我们不能进行外部文件读写。如果需要将jshint命令行化我们需要找到这样一个环境:既能解析js代码,又能进行文件读写。因此我们找到了rhino——一个能解析js代码的java环境[4]。利用java环境,我们读取外部文件提取待检查的js代码,之后利用rhino运行大牛写的jshint.js。
此工具依赖python环境,无需安装。使用也极其简单,只需要进入jshunter的主目录下运行:./hint.py /rest/file/path /path/to/check/*.js就可以了。这里hint.py是主程序的代码,/rest/file/path是该工具生成的报表文件名,/path/to/check/*.js是待检查的文件(支持单个文件和多个文件的代码检查)。程序运行后会根据主目录中的check.cfg配置文件进行检查,该文件各个检查项的具体含义见注释的描述。另外,如果不希望看到某些提示信息,可以将这些信息放到ignore.list黑名单文件中。也就是说,通过check.cfg和ignore.list,用户可以定制符合自己产品线特点的检查策略。
4.小结
本文介绍了和js代码静态检查技术相关的内容。代码检查的成本很低,且确实能发现一些潜在的问题。Jshint是业界一款开源的静态代码检查工具,但在易用性方面存在2个突出的问题,针对目前存在的问题,我们基于JSHint开发的一个命令行方式的代码检查工具jshunter,支持自定义的检查策略配置和黑名单过滤机制,并且能生成格式美观的报表。
转载请注明:爱开源 » 大话js代码静态检查