我应该使用JSLint或JSHint JavaScript验证吗？

Question

我目前正在验证我对JSLint的JavaScript并取得进展,它正在帮助我编写更好的JavaScript - 特别是在使用Jquery库时.

现在我所遇到JSHint,一个叉的JSLint.
所以我想知道很多JavaScript驱动的Web应用程序,这是更好或最适用的验证工具:

• JSLint还是JSHint？

我想现在决定验证机制并继续前进,将其用于客户端验证.

和jshint和jslint之间的区别？请在单个javascript示例中解释.

链接:

1. jshint - http://www.jshint.com/

2. jslint - http://jslint.com/

Answer 1

tl;博士外卖:

如果你正在为自己或团队寻找一个非常高的标准,JSLint.但它不一定是标准,只是一个标准,其中一些来自于一个名叫Doug Crockford的javascript神的教条.如果你想要更灵活,或者你的团队中有一些老东西没有购买JSLint的意见,或者定期在JS和其他C系列语言之间来回,请尝试使用JSHint.

长版:

fork后面的原因解释了为什么JSHint存在:

http://badassjs.com/post/3364925033/jshint-an-community-driven-fork-of-jslint http://anton.kovalyov.net/2011/02/20/why-i-forked-jslint-to -jshint /

所以我想这个想法是它是"社区驱动的"而不是Crockford驱动的.实际上,JSHint通常对JSLint的一些风格和轻微的语法"意见"更加宽容(或至少可配置或不可知).

例如,如果您认为下面的A和B都很好,或者如果您想编写具有A中一个或多个B方面的代码,则JSHint适合您.如果你认为B是唯一正确的选择...... JSLint.我确信还有其他差异,但这突出了一些.

A)开箱即用JSHint - JSLint失败

(function() {
  "use strict";
  var x=0, y=2;
  function add(val1, val2){
    return val1 + val2;
  }
  var z;
  for (var i=0; i<2; i++){
    z = add(y, x+i);
  }
})();

B)传递JSHint和JSLint

(function () {
    "use strict";
    var x = 0, y = 2, i, z;
    function add(val1, val2) {
       return val1 + val2;
    }
    for (i = 0; i < 2; i += 1) {
        z = add(y, x + i);
    }
}());

我个人认为JSLint代码非常好看,而且我不同意它的唯一硬性特征是它在函数和for循环var i = 0声明中对多个var声明的仇恨,以及函数声明的一些空格强制执行. .

JSLint强制执行的一些空白内容,我发现不一定是坏的,但是与家庭中其他语言(C,Java,Python等等)的一些非常标准的空白约定不同步也遵循Javascript中的约定.由于我一整天都在用各种语言写作,并且在我们的代码中与不喜欢Lint风格的空白的团队成员合作,我发现JSHint是一个很好的平衡点.它捕捉的是一个合法的错误或非常糟糕的形式的东西,但不会像JSLint那样咆哮我(有时候,我无法禁用)对于我不关心的风格观点或句法挑剔.

很多好的库都不是Lint'able,这对我来说证明了一些JSLint只是推送1版"好代码"(这确实是好代码)的想法.但话说回来,相同的图书馆(或其他好的图书馆)可能也不是暗示,所以,触摸.

Answer 2

[编辑]
此答案已被编辑.我将在下面留下原始答案的上下文(否则评论没有意义).

当最初询问这个问题时,JSLint是JavaScript的主要linting工具.JSHint是JSLint的一个新分支,但还没有与原来的分歧很多.

从那以后,JSLint几乎保持静态,而JSHint已经改变了很多 - 它抛弃了许多JSLint更多的对抗规则,增加了一大堆新规则,并且通常变得更加灵活.此外,另一个工具ESLint现在可用,它更灵活,有更多的规则选项.

在我原来的回答中,我说你不应该强迫自己坚持JSLint的规则; 只要你理解为什么它会发出警告,你就可以自己判断是否要更改代码以解决警告.

使用2011年JSLint的超严格规则集,这是合理的建议 - 我看到很少有JavaScript代码集可以通过JSLint测试.然而,在今天的JSHint和ESLint工具中提供了更实用的规则,尝试让代码通过零警告是一个更加现实的主张.

可能仍然偶尔会出现一种情况,即linter会抱怨你有意做过的事情 - 例如,你知道你应该总是使用===但只有这一次你有充分的理由使用它==.但即便如此,使用ESLint,您可以选择eslint-disable在相关行周围进行指定,这样您仍然可以通过零警告进行通过lint测试,其余代码遵守规则.(只是不经常做那种事!)

[原始回答]

一定要使用JSLint.但是不要挂在结果上并修复它所警告的一切.它将帮助您改进代码,它将帮助您找到潜在的错误,但不是JSLint抱怨的所有内容都证明是一个真正的问题,所以不要觉得您必须完成零警告的过程.

几乎任何具有任何显着长度或复杂性的Javascript代码都会在JSLint中产生警告,无论它写得多么好.如果您不相信我,请尝试通过它运行一些流行的库,如JQuery.

一些JSLint警告比其他警告更有价值:了解哪些警告需要注意,哪些警告不太重要.应该考虑每个警告,但不要觉得有必要修改你的代码以清除任何给定的警告; 看完代码并决定你对它感到满意是完全可以的; 有时JSlint不喜欢的东西实际上是正确的.

Answer 3

在javascript linting front上还有另一个成熟且积极开发的 "播放器" - ESLint:

ESLint是一种用于识别和报告ECMAScript/JavaScript代码中的模式的工具.在许多方面,它类似于JSLint和JSHint,但有一些例外:

• ESLint使用Esprima进行JavaScript解析.
• ESLint使用AST来评估代码中的模式.
• ESLint是完全可插拔的,每个规则都是一个插件,您可以在运行时添加更多.

这里真正重要的是它可以通过自定义插件/规则进行扩展.已经有多个插件用于不同目的.在别人,主要有:

• eslint-plugin-angular(执行John Papa的角度风格指南中的一些指导原则)
• eslint-插件,茉莉
• eslint-插件骨干

当然,您可以使用您选择的构建工具来运行ESLint:

• 咕噜,eslint
• 一饮而尽,eslint

Answer 4

几个星期前我有同样的问题,并且正在评估JSLint和JSHint.

与这个问题的答案相反,我的结论不是:

一定要使用JSLint.

要么:

如果你正在为自己或团队寻找一个非常高的标准,JSLint.

因为您可以在JSHint中配置与JSLint中几乎相同的规则.所以我认为你可以达到的规则没有太大区别.

所以选择一个而不是另一个的理由更多是政治而非技术.

我们最终决定使用JSHint,原因如下:

• 似乎比JSLint更可配置.
• 看起来更像是社区驱动而不是单人秀(无论男人有多酷).
• JSHint比JSLint更好地匹配我们的代码样式OOTB.

Answer 5

我提出了第三个建议,Google Closure Compiler(以及Closure Linter).你可以在这里尝试一下.

Closure Compiler是一个使JavaScript下载和运行更快的工具.它是JavaScript的真正编译器.它不是从源语言编译成机器代码,而是从JavaScript编译成更好的JavaScript.它解析您的JavaScript,分析它,删除死代码并重写并最小化剩下的内容.它还检查语法,变量引用和类型,并警告常见的JavaScript陷阱.

Answer 6

前言:那很快就升级了.但决定通过它.愿这个答案对您和其他读者有所帮助.

代码提示

虽然JSLint和JSHint是很好用的工具,但多年来我一直很欣赏我的朋友@ugly_syntax所说的:

较小的设计空间.

这是一般原则,就像一个"禅宗僧侣",限制了人们必须做出的选择,一个人可以更富有成效和创造性.

因此我目前最喜欢的零配置JS代码样式:

StandardJS.

更新:

流量有了很大改善.有了它,你可以为你的JS添加类型,这将有助于你防止很多错误.但它也可以保持不受影响,例如在连接无类型JS时.试试看!

快速启动/ TL; DR

standard作为项目的依赖项添加

npm install --save standard

然后package.json,添加以下测试脚本:

"scripts": {
    "test": "node_modules/.bin/standard && echo put further tests here"
},

对于开发时的更流畅的输出,而npm install --global snazzy不是运行它npm test.

注意:类型检查与启发式扫描

我的朋友提到设计空间时提到了榆树,我鼓励你尝试一下这种语言.

为什么？JS实际上受到LISP的启发,LISP是一种特殊的语言类,它恰好是无类型的.诸如Elm或Purescript之类的语言是键入的函数编程语言.

键入限制您的自由,以便编译器能够在您最终违反语言或您自己的程序规则时检查并指导您; 无论程序的大小(LOC)如何.

我们最近有一个初级同事实施了两次反应接口:一次在Elm,一次在React; 看看我正在谈论的是什么.

比较Main.elm(打字)⇔ index.js(无类型,无测试)

(ps.请注意,React代码不是惯用的,可以改进)

最后一句话,

现实是JS 是无类型的.我是谁为你推荐打字节目？

请注意,使用JS我们处于不同的域:从类型中解放出来,我们可以轻松地表达难以或不可能提供适当类型的事物(这当然可以是一个优势).

但是没有类型就没有什么可以控制我们的程序,因此我们不得不引入测试和(在较小的范围内)代码样式.

我建议你看一下LISP(例如ClojureScript)的灵感,并投资测试你的代码.阅读suback的方式来获得一个想法.

和平.

Answer 7

好吧,我们可以在JS文件本身的顶部包含所有lint设置,而不是手动lint设置

声明该文件中的所有全局变量,如:

/*global require,dojo,dojoConfig,alert */

声明所有lint设置,如:

/*jslint browser:true,sloppy:true,nomen:true,unparam:true,plusplus:true,indent:4 */

希望对你有帮助 :)