我应该使用JSLint还是JSHint JavaScript验证?

我目前正在验证我的JavaScript对JSLint和取得进展，它正在帮助我写更好的JavaScript -特别是在与Jquery库工作。

我现在遇到了JSHint， JSLint的一个分支 所以我想知道对于web应用程序，这是非常JavaScript驱动的，哪个是更好的或最适用的验证工具:

  • JSLint还是JSHint?

我现在想要确定一种验证机制，并将其用于客户端验证。

和jshint和jslint的区别?请用javascript实例解释。

链接:

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

  2. <强> jslint < /强> - < a href = " http://jslint.com/ " > http://jslint.com/ < / >

160542 次浏览
小开

我想提出第三个建议，闭包编译器(还有关闭短绒)。你可以在线尝试在这里。

闭包编译器是一个让JavaScript下载和运行更快的工具。它是一个真正的JavaScript编译器。它不是从源语言编译到机器代码，而是从JavaScript编译到更好的JavaScript。它解析你的JavaScript，分析它，删除死代码，重写并最小化剩下的代码。它还检查语法、变量引用和类型，并警告常见的JavaScript陷阱。

小开
最佳答案
< p > (编辑) < br > 以下答案经过编辑。我将下面的原始答案作为上下文(否则评论将没有意义)

当这个问题最初被问到时，JSLint是JavaScript的主要检测工具。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不喜欢的事情实际上是正确的事情

小开
< h1 id = " tldr-z9ve " > TL;博士< / h1 >

如果你正在为自己或你的团队寻找一个非常高的标准，请使用JSLint，但请记住，它不一定是的标准，只有一个标准，其中一些标准教条地来自Doug Crockford。

如果您想要更灵活一点，或者您的团队中有一些老专家不接受JSLint的观点，或者经常在JavaScript和其他c家族语言之间来回切换，请尝试JSHint。

完整版本

有两篇文章解释了JSHint存在的原因:

  1. < p > JSHint: JSLint的一个社区驱动的分支

  2. < p > 为什么我把JSLint分叉到JSHint

JSLint背后的理念是它是社区驱动的，而不是crockford驱动的。JSHint通常对JSLint坚持的一些风格和次要语法意见更宽容(或者至少是可配置的或不确定的)。

例如，如果你认为下面的1.和2.都可以，或者如果你想用1.的一个或多个方面来编写代码，而这些方面在2.中是不可用的，JSHint就是为你准备的。如果你认为2.是唯一正确的选项，使用JSLint。我相信还有其他不同之处，但这里突出了一些。

  1. 从盒子里传递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);
}
})();

  2. 同时传递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代码在视觉上更吸引人。我唯一不同意的特性是它的一个函数中不允许有多个__ABC0声明，也不允许有__ABC1-loop var i = 0声明，以及函数声明中的一些空格强制。

JSLint强制执行的一些空白并不一定是坏的，只是与家族中其他语言(C、Java、Python等)的一些相当标准的空白约定不同步，这些约定在Javascript中也经常遵循。由于我每天都在使用各种语言编写代码，并且与不喜欢lint风格的空格的团队成员一起工作，所以我发现JSHint是一个很好的平衡。它可以捕获合法的错误和非常糟糕的代码，但不会像JSLint那样对我咆哮(有时，以我无法禁用的方式)，因为我不关心的风格意见或语法吹毛求疵。

很多好的库都不能使用Lint，这对我来说证明了JSLint的某些版本只是“好代码”的一个版本的观点是有一定道理的。(这确实是很好的代码)。但是，同样的库(或其他好的库)可能也不具备Hint'able，因此，touché。

小开

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

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

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

声明所有的lint设置，比如:

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

希望这对你有帮助:)

小开

几个星期前我也有同样的问题，当时我正在评估JSLint和JSHint。

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

务必使用JSLint。

或者:

如果您正在为自己或团队寻找一个非常高的标准，JSLint。

因为你可以在JSHint中配置与JSLint相同的几乎规则。所以我认为你所能实现的规则并没有太大的不同。

因此，选择一个而不是另一个的原因更多是政治上的，而不是技术上的。

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

  • 似乎比JSLint更可配置。
  • 看起来绝对是社区驱动的，而不是一个人的表演(不管这个男人有多酷)。
  • JSHint比JSLint更符合我们的代码风格OOTB。
小开

在javascript linting前面有另一个成熟，积极发展“播放器”- ESLint:

ESLint是一个用于识别和报告在ESLint中发现的模式的工具 ECMAScript / JavaScript代码。在许多方面，它类似于JSLint和 JSHint有几个例外:

  • ESLint使用Esprima进行JavaScript解析。
  • ESLint使用AST来计算代码中的模式。
    • ESLint是完全可插拔的 单个规则是一个插件，你可以在运行时添加更多的规则

这里真正重要的是它是可通过自定义插件/规则扩展。已经为不同的目的编写了多个插件。在其他人中，有:

  • eslint-plugin-angular(强制执行John Papa的Angular风格指南中的一些指导原则)
  • < a href = " https://www.npmjs.com/package/eslint-plugin-jasmine " > eslint-plugin-jasmine < / >
  • < a href = " https://www.npmjs.com/packages/eslint-plugin-backbone " > eslint-plugin-backbone < / >

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

  • < a href = " https://www.npmjs.com/package/grunt-eslint " > grunt-eslint < / >
  • < a href = " https://www.npmjs.com/package/gulp-eslint " > gulp-eslint < / >
小开

还有另一个积极开发的替代方案——JSCS - JavaScript代码风格:

JSCS是一个代码风格检测器，用于以编程方式强制执行您的风格 指南。您可以使用over为您的项目详细配置JSCS 150条验证规则，包括流行风格指南中的预设 jQuery, Airbnb，谷歌和更多

它带有多个预设，你可以通过简单地在.jscsrc配置文件中指定preset并自定义它来进行选择——覆盖、启用或禁用任何规则:

{
"preset": "jquery",
"requireCurlyBraces": null
}

还有为流行编辑器构建的插件和扩展。

还看到:

小开

前言:嗯，事态迅速升级。但我决定挺过去。希望这个答案对你和其他读者有所帮助。

I got a bit carried away here

代码提示

虽然JSLint和JSHint是很好的工具，多年来，我已经开始欣赏我的朋友@ugly_syntax调用:

较小的设计空间。

这是一个普遍的原则，就像一个“禅僧”，限制一个人必须做出的选择，一个人可以更有成效和创造性。

因此，我目前最喜欢的零配置JS代码风格:

StandardJS。

更新:

流改进了很多。有了它，你 可以添加类型到你的JS与将帮助你防止很多 的病菌。但它也可以不碍事，比如 在接口非类型化JS时。试试吧!< / p >

快速入门/ TL

将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(无类型，无测验)

(注:React代码不是惯用的，可以改进)

最后一点，

事实上，JS 是是无类型的。我有什么资格向你建议类型的编程 ?

看，有了JS，我们处在一个不同的领域:从类型中解放出来，我们可以轻松地表达那些很难或不可能给出正确类型的东西(这当然是一个优势)。

但是如果没有类型，我们的程序就无法得到控制，所以我们不得不引入测试和(在较小范围内)代码样式。

我建议你看看LISP(例如ClojureScript的)的灵感和投资测试你的代码。阅读子堆栈的方式来了解一下。

和平。


提交答案