web-dev-qa-db-ja.com

JSLintまたはJSHint JavaScript検証を使用する必要がありますか?

私は現在JSLintに対して私のJavaScriptを検証していて進歩しています、それは私がより良いJavaScriptを書くのを助けています - 特にJqueryライブラリを扱うことにおいて。

私は今JSHintJSLintのフォークを見つけました。
それで、私はJavaScriptが動かされているWebアプリケーションを考えています。

  • JSLintかJSHintか

バリデーションのメカニズムを決めて先に進みたいので、これをクライアントサイドのバリデーションに使います。

そしてjshintとjslintの違いは?単一のjavascriptの例で説明してください。

リンク集

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

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

447
amateur

[編集]
この回答は編集されています。私は文脈のために以下の元の答えを残しています(さもなければコメントは意味をなさないでしょう)。

この質問が最初に尋ねられたとき、JSLintはJavaScriptのための主要なリンティングツールでした。 JSHintはJSLintの新しいフォークでしたが、まだ元のものとはあまり異なっていません。

それ以来、JSLintはかなり静的なままですが、JSHintは大幅に変更されました - それは、JSLintのより拮抗的な規則の多くを捨て、新しい規則をたくさん追加し、そして一般により柔軟になりました。また、もう1つのツールESLintが利用可能になりました。これはさらに柔軟で、より多くのルールオプションがあります。

私の最初の答えでは、私はあなたがJSLintの規則に固執することをあなた自身に強制するべきではないと言った。警告を投げた理由を理解している限り、警告を解決するためにコードを変更するかどうかについて自分で判断することができます。

2011年のJSLintの非常に厳密なルールセットでは、これは妥当なアドバイスでした。JSLintテストに合格することができるJavaScriptコードセットはほとんどありません。しかし、今日のJSHintおよびESLintツールでは、より実用的な規則が使用可能であるため、コードを警告なしで通過させることを試みるのがより現実的な提案です。

あなたが意図的に行ったことについてリンターが文句を言うケースがまだ時々あるかもしれません - 例えば、あなたはいつも===を使うべきだと知っていますが、これは==を使うもっともな理由です。しかしそれでも、ESLintでは問題の行の周りにeslint-disableを指定することができるので、警告なしで合格lintテストを行うことができ、残りのコードはその規則に従います。 (そのようなことをあまり頻繁に行わないでください。)


[元の回答に従う] [

ぜひJSLintを使ってください。しかし、結果に警告したり、警告が表示されたものをすべて修正したりしないでください。それはあなたがあなたのコードを改良するのを助けます、そしてそれはあなたが潜在的なバグを見つけるのを助けますが、JSLintが不平を言っていることすべてが本当の問題であると判明します。

それがどれほど上手に書かれていようとも、かなりの長さまたは複雑さを持つほとんどすべてのJavascriptコードがJSLintで警告を出します。私を信じていないのであれば、それを通してJQueryのようないくつかの人気のあるライブラリを実行してみてください。

JSLintの警告の中には、他のものよりも価値があるものがあります。あらゆる警告を考慮する必要がありますが、与えられた警告をクリアするようにコードを修正する義務はありません。コードを見て満足していると判断してもまったく問題ありません。 JSlintが気に入らないことが実際に正しいことである場合があります。

152
Spudley

tl; drテイクアウト

あなた自身やチームのために非常に高い標準を探しているなら、JSLint。しかしそれは必ずしも標準ではなく、単なる標準であり、そのうちのいくつかはDoug Crockfordという名前のjavascriptの神から独断的に私たちにもたらされます。もう少し柔軟にしたい、またはJSLintの意見を聞き入れない、またはJSと他のCファミリ言語の間を定期的に行ったり来たりしている古いプロをチームの中に入れたい場合は、JSHintを試してください。

ロングバージョン

フォークの背後にある推論は、JSHintが存在する理由をかなりよく説明します。

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

それで、私はその考えが、それがCrockford主導ではなく「コミュニティ主導」であると思います。実用的には、JSHintは一般的に、JSLintが固執する少数の文体的でマイナーな構文上の「意見」に対して、もう少し寛容です(または少なくとも構成可能または不可知論的)。

例として、以下のAとBの両方が問題ないと思う場合、またはBで利用できないAの1つ以上の側面を持つコードを書きたい場合は、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コードを見てとてもうれしいと思います、そして私が賛成できない唯一の難しい機能はそれが 関数内の複数のvar宣言とfor-loop var i = 0宣言の憎悪です。 、および関数宣言のためのいくつかの空白強制。

JSLintが強制するいくつかの空白文字は、必ずしも悪いわけではありませんが、ファミリー内の他の言語(C、Java、Pythonなど)のかなり標準的な空白の規約とは一致していません。 Javascriptの規約としても同様です。私は一日中これらの言語で書いていて、私たちのコードの中でLintスタイルの空白が好きではないチームメンバーと仕事をしているので、私はJSHintが良いバランスであると思います。それは合法的なバグや本当に悪い形のものをキャッチしますが、JSLintが(時々、私は無効にできない方法で)気にしない文法的な意見や構文の抜粋のために吠えません。

多くの優れたライブラリはLint'ableではありません、それは私にとってJSLintのいくつかは単に "良いコード"の1つのバージョンをプッシュすることについてのアイデアに真実があることを示しています。しかし、繰り返しますが、同じライブラリ(または他の良いライブラリ)もおそらくヒントにはなりません。

369
Ben Roberts

JavaScriptリンティングの前面には、もう1つの成熟して積極的に開発された「プレーヤー」があります - ESLint

ESLintはECMAScript/JavaScriptコードに見られるパターンを識別して報告するためのツールです。多くの点で、JSLintとJSHintに似ていますが、いくつか例外があります。

  • ESLintはJavaScriptの解析にEsprimaを使用しています。
  • ESLintはコード内のパターンを評価するためにASTを使用します。
  • ESLintは完全にプラグイン可能で、すべてのルールはプラグインであり、実行時にさらに追加できます。

ここで本当に重要なのは、それがカスタムプラグインを介して拡張可能であることです/規則。さまざまな目的のために書かれたプラグインがすでに複数あります。 他の人 には、次のものがあります。

そしてもちろん、あなたは自分の選んだビルドツールを使ってESLintを実行することができます。

59
alecxe

私は数週間前に同じ質問をし、JSLintとJSHintの両方を評価していました。

この質問の答えに反して、私の結論はそうではありませんでした:

ぜひJSLintを使ってください。

または

あなた自身やチームのために非常に高い標準を探しているなら、JSLint。

JSHintでもほぼJSLintと同じルールを設定できます。だから私はあなたが達成できるルールに大きな違いはないと主張するでしょう。

そのため、次を選ぶ理由は技術的よりも政治的です。

次の理由から、JSHintを使用することにしました。

  • そのJSLintよりも設定可能であるように思われます。
  • ワンマンショーよりもコミュニティ主導の方が確実に見えます(The Manがどれほどクールでも).
  • JSHintは、私たちのコードスタイルOOTBに、JSLintよりも優れています。
17
lexicore

はじめに:まあ、それは急速にエスカレートしました。しかしそれを通すことにしました。この答えがあなたや他の読者の役に立つことを願います。

I got a bit carried away here

コードヒンティング

JSLintとJSHintは使用するのに適したツールですが、長年にわたって私の友人 @ ugly_syntax が何を呼んでいるのか理解するようになりました。

小さいデザインスペース

これは一般的な原則であり、「禅の僧侶」とよく似ていますが、選択を制限し、生産性と創造性を高めることができます。

したがって、私の現在のお気に入りのゼロ構成のJSコードスタイルは次のとおりです。

StandardJS .

UPDATE

Flow が大幅に改善されました。それを使えば、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の代わりにそれを実行してください。

注:型チェックとヒューリスティック

デザインスペースについて言及する際の私の友人は、 Elm を参照しました。その言語を試してみることをお勧めします。

どうして? JSは実際にはLISPに触発されています。LISPは特殊なクラスの言語で、untypedです。 Elmや Purescript などの言語は、typed関数型プログラミング言語です。

あなたが言語やあなた自身のプログラムの規則に違反することになったときにコンパイラがあなたをチェックしてガイドできるようにするためにはタイプをあなたの自由を制限します。プログラムのサイズ(LOC)に関係なく。

私たちは最近、後輩の同僚にリアクティブインタフェースを2回実装させました。1回はElmに、もう1回はReactに。私が何について話しているのかという考えを得るために見てください。

Main.Elm (型付き)⇔ index.js (型なし、テストなし)

(ps。Reactコードは慣用的なものではなく、改善される可能性があることに注意してください)

最後の一言、

現実は、JSuntypedです。型付きプログラミングをあなたに勧めたいのは誰ですか?

JSでは、私たちは別の領域にいます。型から解放されているので、適切な型を与えるのが難しい、または不可能なことを簡単に表現できます(確かに利点になることがあります)。

しかし、型がなければプログラムをチェックするのにほとんど意味がないので、テストと(より少ない範囲で)コードスタイルの導入を余儀なくされます。

インスピレーションを得るためにLISP(例: ClojureScript )を調べて、コードのテストに投資することをお勧めします。アイデアを得るために サブスタックの方法 を読んでください。

平和。

13
wires

私は3番目の提案をしたいと思います、 Google Closure Compiler (そして Closure Linter )。あなたはそれをオンラインで試すことができます ここ

Closure Compilerは、JavaScriptのダウンロードと実行を高速化するためのツールです。それはJavaScript用の真のコンパイラです。ソース言語からマシンコードにコンパイルする代わりに、JavaScriptからより良いJavaScriptにコンパイルします。それはあなたのJavaScriptをパースし、それを分析し、デッドコードを取り除きそして書き換えそして残されるものを最小にします。また、構文、変数の参照、および型もチェックし、一般的なJavaScriptの落とし穴について警告します。

13
Jeff Foster

手動のlint設定を行う代わりに、JSファイル自体の先頭にすべてのlint設定を含めることができます。

そのファイルのすべてのグローバル変数を次のように宣言します。

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

すべてのlint設定を次のように宣言します。

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

これがお役に立てば幸いです:)

8
Vikash Pandey

他にも活発に開発されているものがあります - JSCS - JavaScriptコードスタイル

JSCSはプログラムでスタイルガイドを強制するためのコードスタイルリンターです。 jQuery、Airbnb、Googleなどの一般的なスタイルガイドのプリセットを含む、150を超える検証ルールを使用して、プロジェクト用にJSCSを詳細に設定できます。

.jscsrc設定ファイルでpresetを指定してカスタマイズすることで選択できる複数の プリセット が付属しています。

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

人気のあるエディタ用に構築されたプラグインと拡張機能もあります。

また見なさい:

1
alecxe