私は現在、JavaScriptをJSLintに対して検証しており、進歩を遂げています。これは、特にJqueryライブラリの操作において、より優れたJavaScriptを作成するのに役立ちます。
JSLintのフォークであるJSHintに出くわしました。
ですから、JavaScriptが非常に駆動されているWebアプリケーションについて疑問に思っています。これは、以下に対して機能する、より優れた、または最も適切な検証ツールです。
ここで検証メカニズムを決定し、先に進みます。これをクライアント側の検証に使用します。
そして、jshintとjslintの違いは？単一のJavaScriptの例で説明してください。
リンク：
jshint - http: //www.jshint.com/
jslint - http: //jslint.com/
自分自身またはチームにとって非常に高い標準を探している場合はJSLintを使用しますが、これは必ずしも標準ではなく、標準にすぎないことを覚えておいてください。その一部はDougCrockfordから独断的に提供されます。
もう少し柔軟になりたい場合、またはJSLintの意見に賛成しない、またはJavaScriptと他のCファミリー言語の間を定期的に行き来している古いプロがチームにいる場合は、JSHintを試してください。
フォークの背後にある理由を含む2つの記事で、JSHintが存在する理由を説明しています。
JSLintの背後にある考え方は、Crockford主導ではなく、コミュニティ主導であるということです。JSHintは、一般的に、JSLintが固執するいくつかの文体的でマイナーな構文上の意見に対して、より寛大です（または少なくとも構成可能または不可知論的です）。
たとえば、以下の1.と2.の両方で問題ないと思う場合、または2.で利用できない1.の側面の1つ以上を使用してコードを記述したい場合は、JSHintが最適です。2.が唯一の正しいオプションだと思う場合は、JSLintを使用してください。他にも違いがあると思いますが、これはいくつかの違いを浮き彫りにします。
箱から出して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);
}
})();
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コードの方が視覚的に魅力的だと思います。私が同意しない唯一の機能は、関数内の複数の宣言と-loop宣言varforvar i = 0に対する憎しみ、および関数宣言に対する空白の強制の一部です。
JSLintが適用する空白のいくつかは必ずしも悪いわけではありませんが、Javascriptの規則としてよく従われる、ファミリ内の他の言語（C、Java、Pythonなど）のかなり標準的な空白の規則と同期していません。私はこれらのさまざまな言語で1日中書いていて、コード内のLintスタイルの空白が気に入らないチームメンバーと協力しているので、JSHintはバランスが取れていると思います。正当なバグや非常に不適切な形式のコードをキャッチしますが、JSLintのように（場合によっては無効にできない方法で）、私が気にしない文体の意見や構文上の落とし穴に対して吠えません。
多くの優れたライブラリはLint'ableではありません。これは、JSLintの一部が「優れたコード」（実際には優れたコード）の1つのバージョンをプッシュするだけであるという考えには真実があることを示しています。しかし、繰り返しになりますが、同じライブラリ（または他の優れたライブラリ）もおそらくヒントになりません。
[編集]
この回答は編集されました。コンテキストのために元の回答を以下に残します（そうしないと、コメントは意味がありません）。
この質問が最初に尋ねられたとき、JSLint は JavaScript の主要な lint ツールでした。JSHint は JSLint の新しいフォークでしたが、まだ元のものからあまり分岐していませんでした。
それ以来、JSLint はほとんど静的なままでしたが、JSHint は大幅に変更されました。JSLint のより敵対的なルールの多くが破棄され、新しいルールが大量に追加され、全体的により柔軟になりました。また、さらに柔軟で、より多くのルール オプションを備えた別のツール ESLint が利用可能になりました。
私の最初の回答では、JSLint の規則に固執することを強制すべきではないと言いました。警告がスローされた理由を理解している限り、コードを変更して警告を解決するかどうかを自分で判断できます。
2011 年の JSLint の非常に厳格なルールセットでは、これは合理的なアドバイスでした。JSLint テストに合格できる JavaScript コードセットはほとんど見たことがありません。ただし、今日の JSHint および ESLint ツールで利用できるより実用的なルールを使用すると、警告なしでコードを通過させることがより現実的な提案になります。
意図的に何かを行ったことに対してリンターが文句を言うケースがまだ時折あるかもしれませ===ん==。しかしそれでも、ESLint を使用するとeslint-disable、問題の行の周囲を指定するオプションがあるため、警告なしで lint テストに合格し、残りのコードはルールに従います。（そのようなことをあまり頻繁にしないでください！）
[元の回答が続きます]
ぜひJSLintを使ってください。ただし、結果や、警告が表示されるすべての修正にとらわれないでください。コードを改善し、潜在的なバグを見つけるのに役立ちますが、JSLint が訴えるすべてが実際の問題であるとは限らないため、警告なしでプロセスを完了する必要があるとは思わないでください。
非常に長いまたは複雑な Javascript コードは、どれほど適切に記述されていても、JSLint で警告を生成します。信じられない場合は、JQuery などの一般的なライブラリを実行してみてください。
一部の JSLint 警告は他の警告よりも価値があります。どの警告に注意し、どの警告がそれほど重要でないかを学びます。すべての警告を考慮する必要がありますが、特定の警告をクリアするためにコードを修正する必要はありません。コードを見て、満足していると判断してもまったく問題ありません。JSlint が好まないことが実際には正しいことである場合があります。
数週間前に同じ質問があり、JSLint と JSHint の両方を評価していました。
この質問の答えに反して、私の結論はそうではありませんでした：
ぜひJSLintを使ってください。
または：
あなた自身またはチームのために非常に高い基準を探しているなら、JSLint.
JSHint では、JSLint とほぼ同じルールを設定できるためです。したがって、達成できるルールに大きな違いはないと私は主張します。
したがって、どちらかを選択する理由は、技術的というよりも政治的なものです。
次の理由により、最終的に JSHint を使用することにしました。
3つ目の提案として、Google ClosureCompiler （およびClosureLinter）を提案します。ここでオンラインで試すことができます。
ClosureCompilerはJavaScriptのダウンロードと実行を高速化するためのツールです。これはJavaScript用の真のコンパイラです。ソース言語からマシンコードにコンパイルする代わりに、JavaScriptからより優れたJavaScriptにコンパイルします。JavaScriptを解析して分析し、デッドコードを削除して書き直し、残っているものを最小限に抑えます。また、構文、変数参照、および型をチェックし、一般的なJavaScriptの落とし穴について警告します。
序文: うーん、それはすぐにエスカレートしました。しかし、それを引っ張ることにしました。この回答があなたや他の読者の役に立ちますように。
JSLint と JSHint は使用するのに適したツールですが、何年にもわたって、友人の@ugly_syntaxが次のように呼んでいることに感謝するようになりました。
より小さなデザインスペース。
これは一般的な原則であり、「禅僧」のように、選択を制限することで、生産性と創造性を高めることができます。
したがって、私の現在のお気に入りのゼロ設定 JS コード スタイルは次のとおりです。
標準JS .
更新：
流れがかなり良くなりました。これを使用すると、多くのバグを防ぐのに役立つ型を JS に追加できます。ただし、型指定されていない JS とのインターフェイスなど、邪魔にならないこともあります。試してみる！
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に言及していました。Elmの言語を試してみることをお勧めします。
なんで？実際、JS は LISP に触発されています。LISP は特殊な言語クラスであり、たまたまuntypedです。Elm やPurescriptなどの言語は、型付き関数型プログラミング言語です。
言語または独自のプログラムの規則に違反したときにコンパイラがチェックしてガイドできるように、自由を制限してください。プログラムのサイズ (LOC) に関係なく。
最近、後輩の同僚にリアクティブ インターフェイスを 2 回実装してもらいました。Elm で 1 回、React で 1 回です。私が何について話しているのかを理解するために見てください。
(ps. React コードは慣用的なものではなく、改善される可能性があることに注意してください)
現実には、JSは型指定されていません。型付きプログラミングを提案する私は誰ですか?
JS を使用すると、私たちは別のドメインにいます。型から解放され、適切な型を与えることが困難または不可能なものを簡単に表現できます (これは確かに利点です)。
しかし、型がなければ、プログラムを制御することはほとんどできないため、テストと (それほどではありませんが) コード スタイルを導入する必要があります。
インスピレーションを得るために LISP (例: ClojureScript ) を調べ、コードのテストに投資することをお勧めします。アイデアを得るには、サブスタックの方法を読んでください。
平和。
手動で lint 設定を行う代わりに、すべての lint 設定を JS ファイル自体の先頭に含めることができます。
そのファイル内のすべてのグローバル変数を次のように宣言します。
/*global require,dojo,dojoConfig,alert */
すべての lint 設定を次のように宣言します。
/*jslint browser:true,sloppy:true,nomen:true,unparam:true,plusplus:true,indent:4 */
これがあなたを助けることを願っています:)
活発に開発されている別の代替手段もあります - JSCS — JavaScript Code Style :
JSCS は、スタイル ガイドをプログラムで強制するためのコード スタイル リンターです。jQuery、Airbnb、Google などの一般的なスタイル ガイドのプリセットを含む、150 を超える検証ルールを使用して、プロジェクトの JSCS を詳細に構成できます。
構成ファイルで を指定してカスタマイズするだけで選択できる複数のプリセットが付属しています。ルールをオーバーライド、有効化、または無効化します。preset.jscsrc
{
"preset": "jquery",
"requireCurlyBraces": null
}
人気のあるエディター向けに構築されたプラグインと拡張機能もあります。
以下も参照してください。