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

时间：2011-07-23 21:04:50

标签： javascript jslint jshint

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

我现在遇到 JSHint ， JSLint 的分支。
所以我想知道很多JavaScript驱动的Web应用程序，这是更好或最适用的验证工具：

  • JSLint还是JSHint？

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

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

链接：

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

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

8 个答案:

答案 0 :(得分：369)

tl; dr takeaway ：

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

长版：

分叉背后的原因很好地解释了为什么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代码非常好看，而且我不同意它的唯一硬性特征是它的hatred of more than one var declaration in a function and of for-loop var i = 0 declarations，以及函数声明的一些空白强制执行。

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

很多好的库都不是Lint'able，这对我来说证明了一些JSLint只是推送1版“好代码”（这确实是好代码）的想法是有道理的。 ）。但话说回来，相同的图书馆（或其他好的图书馆）可能也不是暗示，所以，触摸。

答案 1 :(得分：152)

<强> [编辑]
这个答案已被编辑。我将在下面留下原始答案以供上下文使用（否则评论没有意义）。

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

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

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

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

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

[原始答案]

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

<击>

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

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

答案 2 :(得分：59)

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

  

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

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

这里真正重要的是可通过自定义插件/规则扩展。已经有多个插件用于不同目的。在others中，有：

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

答案 3 :(得分：17)

几个星期前我遇到了同样的问题，并且正在评估JSLint和JSHint。

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

  

一定要使用JSLint。

或者：

  

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

您可以在JSHint中配置几乎相同的规则，就像在JSLint中一样。所以我认为你可以达到的规则差别不大。

因此选择一个而不是另一个的理由更多是政治而非技术。

由于以下原因，我们最终决定使用JSHint：

  • 似乎更容易配置JSLint。
  • 看起来更像是社区驱动而不是单人秀（无论男人是多么酷）。
  • JSHint比JSLint更符合我们的代码风格OOTB。

答案 4 :(得分：13)

我会提出第三个建议，Google Closure Compiler（以及Closure Linter）。您可以在线试用here。

  

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

答案 5 :(得分：13)

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

I got a bit carried away here

代码提示

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

  

更小的设计空间。

这是一般原则，就像“禅宗僧侣”一样，限制了人们必须做出的选择，可以提高工作效率和创造力。

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

  

StandardJS

<强>更新：

Flow改善了很多。有了它，你 可以为你的JS添加类型，可以帮助你防止很多 虫子但是，例如，它也可以让您不受阻碍 当连接无类型的JS时。试一试！

快速入门/ TL; DR

将standard添加为项目的依赖项

npm install --save standard

然后在package.json中添加以下测试脚本：

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

对于开发过程中的snazzier输出，npm install --global snazzy并运行它而不是npm test。

注意：类型检查与启发式

我的朋友提到Elm时提到的设计空间，我鼓励你试试这种语言。

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

类型限制您的自由，以便编译器能够在您最终违反语言或您自己的程序规则时检查并指导您;无论程序的大小（LOC）如何。

我们最近有一位初级同事实施了两次被动接口：一次在Elm，一次在React;看看我在谈论的是什么。

  

比较Main.elm（已键入）⇔index.js（无类型，无测试）

（ps。请注意，React代码不是惯用的，可以改进）

最后一句话，

现实是JS 是无类型的。我是谁建议打字编程给你？

参见JS，我们处于不同的领域：从类型中解放出来，我们可以很容易地表达难以或不可能提供正确类型的东西（这当然是一种优势）。

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

我建议您查看LISP（例如ClojureScript）获取灵感，并投资测试您的代码。阅读The way of the substack以获得想法。

和平。

答案 6 :(得分：8)

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

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

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

声明所有lint设置，如：

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

希望这会对你有所帮助:)。

答案 7 :(得分：1)

还有另一个积极开发的替代方案 - JSCS — JavaScript Code Style：

  

JSCS是一种代码样式的linter，用于以编程方式强制执行您的样式   指南。您可以使用over为您的项目详细配置JSCS   150个验证规则，包括来自流行样式指南的预设   jQuery，Airbnb，Google等。

它附带了多个presets，只需在preset配置文件中指定.jscsrc并自定义它即可选择 - 覆盖，启用或禁用任何规则：

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

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

另见：

相关问题
最新问题