知識星球
作者：百度efe – 我佛山人（@i我佛山人）
網址：http://efe.baidu.com/blog/js-lints/?qq-pf-to=pcqq.c2c
點選“閱讀原文”可檢視本文網頁版
自鴻蒙初判，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.
再看它的 package.json 中的依賴包：
“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。然而，espree 對 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，可作參考。