JavaScript 代碼靜態質量檢查
自鴻蒙初判，Brendan Eich 10 天捏出 Mocha 之后，即便進化成 EcmaScript，這個語言依舊毀譽相隨。那些經過重重劫難，僥幸渡劫成功的苦主標識了諸多天坑（見 JavaScript Garden） —— 當然，你也可以稱之 feature。據無責任亂猜，Douglas Crockford 也沒少踩坑，于是才有了蝴蝶書《JavaScript: The Good Parts》，下雨天與JSLint一起使用會更配喲。
《JavaScript: The Definitive Guide》 V.S. 《JavaScript: The Good Parts》
時至今日，代碼的靜態質量檢查在項目質量保障方面的重要性與必要性已毋庸置疑。越來越多的開發者意識到了這一點，紛紛在項目構建流程或者源碼控制系統中添加靜態檢查的hook。本文將依時間順序，選出JavaScript史上的主要幾個Linter作橫向比較，最終屬意誰家，那就見仁見智了。
JSLint
JSLint的名字源于早期用于檢查C語言代碼質量的Lint，老道把認為非Good Parts、有陷阱的部分全部報 warning，而且絕不允許妥協（當前版本已經允許部分的可配置項），固執得令人心疼。
雖然這個在 2002 年的 JSLint 代表著先進的方向，但是前端的發展一日千里，嚴格不妥協的JSLint開始阻礙前端的發展 —— 例如函數內變量全部集中在頂部定義，推薦一個var定義多個變量等。最最最重要的是，老道拒絕開源JSLint（無責任亂猜，也許JSLint的實現代碼違反它自己制定的規則）。
截止 2015年6月9日，JSLint仍然在更新，官網上寫著 JSLint edition 2015-06-02 BETA，固執的老道。
JSHint
鑒于JSLint的現狀，Anton Kovalyov 以JSLint為藍本，在社區力量的幫助下實現了開源的JSHint。
相較之下，JSHint更友好，可配置性更高。由于大家受JSLint的壓迫太久，而且得益于開源的優勢，風頭很快蓋過JSLint，一時無兩，獲得大量 IDE/Editor 的支持。然而成敗蕭何，JSHint的成功源于對JSLint的改進，但同樣繼承了JSLint的諸多缺點，比如不易擴展，難以根據報錯信息定位到具體的規則配置等。雖然有專門的文檔說明，但是修復的成本仍舊不低，于是出現了 JSLint Error Explanations 這樣的網站，針對JSLint/JSHint/ESLint報的錯誤作修復說明 —— “啪啪”，這對JSHint團隊來說無異于打臉。
JSHint團隊也逐漸意識到這個問題的重要性，2012 年時曾有 討論 使用esprima生成 AST（見 jshint-next，提示該項目已過期，已 merge 到主項目，但在 2013/5 又從主項目移除，現已難覓芳蹤，原因未明），并有專門針對JSHint的 warning 作修復的 fixmyjs。
Closure Linter
Closure Linter屬于Closure家族成員，源于 2004 年的Gmail項目，最初只是內部使用，后來覺得應當兼濟天下，于是在 2007 年后作為Closure Tools系列開放給外部使用。Closure Linter主要是按照《Google JavaScript Style Guide》來作檢查與修復。限于Closure的家族特性，使用范圍并不大。
JSCS
自Marat Dulin于2003.6.17日凌晨發布第一個版本開始，JSCS就專注于代碼風格層面的檢查，這點從它的名字JSCS - JavaScript Code Style中可窺一斑：
JSCS is a code style linter for programmatically enforcing your style guide. You can configure JSCS for your project in detail using over 90 validation rules, including presets from popular style guides like jQuery, Airbnb, Google, and more.
</blockquote>再看它的package.json中的依賴包：
</tr> </tbody> </table> "dependencies": { "esprima": "^1.2.5", "esprima-harmony-jscs": "1.1.0-bin", "estraverse": "^1.9.3", }可以發現它使用了esprima生成 AST，再通過estraverse遍歷作檢查，因此性能上會遜于JSLint與JSHint，但是帶來的收益是易于維護和擴展，相對于性能上的損失，是完全值得的。另外，JSCS可通過esprima-harmony-jscs實現對ES6的支持，并且自帶錯誤修復技能。
JSCS與JSHint份屬同盟，互相使用對方作本項目的代碼檢查。
ESLint
無獨有偶，同樣是源于對JSLint與JSHint的不滿，Nicholas C. Zakas 也在JSCS發布的當月開始造另一個新輪子 ——JSCheck（濃濃的山寨感撲面而來有沒有），不過幾天后即更名為ESLint—— 再次表明，好名字重要性。
功能方面，ESLint可以簡單的理解成JSHint + JSCS，基本上集成了兩大基友的優點。ESLint在初期也是依賴于esprima生成 AST，后來為提高對 ES6 的支持，換成esprima的分支版本espree。然而，espress對 ES6 的支持仍然很有限，不過好在還有 Babel-ESLint。
總結
如果你是老道的死忠粉，無條件同意他關于 JavaScript 的一切觀點，那么JSLint是你的不二選擇。只要把 老道 換成 Google 成立，JSLint換成Closure Linter同樣成立。
如果你有良好的單元測試作后續的質量保證，或者只 care 代碼風格方面的問題，那么JSCS就完全勝任。
如果你要求不高，更注重開發工具和環境的支持，還想順便檢查一下 HTML 代碼中的inline script，嚴重推薦JSHint。得益于它的高普及度，即使官方文檔有隔靴搔癢的無力感，在社區的幫助下也能很快的解決你的問題。
如果你的要求非常高，為團隊制定規范非常詳細，并且不滿足于JSHint與JSCS的組合，不妨試試ESLint。嚴格的貢獻參與流程，快速的響應以及豐富的文檔都不過是它諸多優點中的冰山一角。
你還要檢查 CSS 和 HTML，甚至還有 Less？ 也許只有fecs可以拯救你于水火，至于fecs是什么，那是另一篇文章的內容了。
補充
行文未完，微博發現已有類似的比較： A Comparison of JavaScript Linting Tools，可作參考。
來自: http://efe.baidu.com/blog/js-lints/
本文由用戶 jopen 自行上傳分享，僅供網友學習交流。所有權歸原作者，若您的權利被侵害，請聯系管理員。轉載本站原創文章，請注明出處，并保留原始鏈接、圖片水印。本站是一個以用戶分享為主的開源技術平臺，歡迎各類分享！相關經驗
相關資訊
sesese色