javascript檢驗工具的比較

做者是 Jani Hartikainen，英文好的同窗直接閱讀原文。 原文

當寫js代碼的時候，一個校驗工具能夠幫助我避免愚蠢的錯誤。儘管我有許多年的經驗，可是我仍然有變量命名不正確、產生語法錯誤以及忘記正確處理錯誤。在我浪費時間，尤爲是客戶時間以前，一個好的校驗工具或校驗器能夠告訴我這些問題。好的校驗工具能夠確保一個項目遵循代碼規範。

存在四個可使用的js校驗器，可是怎麼選擇使用哪個呢？接下來讓咱們看看這四種流行方案的特色、優勢和不足：JSLint、JSHint、JSCS、ESLint。

Overview

四種工具用相同的基本方式工做。他們都有一套用戶分析、報告js文件錯誤的規則。他們均可以經過npm安裝。他們均可以經過命令行使用、做爲Grunt插件使用、也能夠集成到編輯器中。他們四種均支持使用註釋進行配置。

可是類似點結束了。每一個工具都有各自的優勢和缺點–優勢是經過比較獲得的。

JSLint

JSLint是其中最老的工具。在2002年 Douglas Crockford開發了該工具，根據其經驗，強制使用js語言中精粹的部分。若是你贊成這些精粹，JSLint能成爲一個好的工具。

JSLint的缺點是不能配置和拓展。你根本不能禁掉須要特性，而且不少缺乏文檔。官方文檔很是不友好，例如缺乏如何將其集成到編輯的信息。

優勢

• 參數配置完成，能夠直接使用

缺點

• JSLint不存在配置文件，若是想改變參數設置，那就存在問題
• 有限的配置選項，許多規則不能禁掉
• 不能增長個性化規則
• 沒有文檔記錄規則
• 很難弄清楚哪一個規則引發的錯誤

JSHint

做爲一個可配置的JSLint版本，JSHint被開發出來。你能夠配置每一個規則，將其放到一個配置文件中，這樣在大項目中能夠容易使用。JSHint對每一個規則有好的文檔，因此能夠準確知道每一個規則的做用。將其集成到編輯器也是簡單的。

JSHint的一個小缺點是裏面的鬆散默認配置。也便是你在使其可用以前必須將其啓動。和ESLint相比，肯定哪一個規則用戶開啓或關閉錯誤信息，JSHint是更加困難。

優勢

• 大可能是參數能夠配置
• 支持配置文件，在大項目中容易使用
• 已經支持須要類庫，像jQuery、QUnit、NodeJS、Mocha等
• 支持基本的ES6

缺點

• 難於知道哪一個規則產生錯誤
• 存在兩類選項：強制選項和鬆散選項。使得配置有些混亂
• 不支持自定義規則

JSCS

JSCS不一樣於其餘，由於若是不給它一個配置文件或告訴它一個配置項，JSCS
不會作任何事情。能夠存他們的網站如今配置項，因此這不是個大問題，而且有許多配置項，例如jQuery代碼風格配置項、Google配置項。

它有超過90個不一樣的規則，經過插件能夠建立自定義規則。當和其餘工具集成須要特定格式時，JSCS也支持自定義報告使得變得很是容易。

JSCS是一個代碼風格檢查器。這意味着它僅僅匹配代碼格式的問題，不匹配潛在的bugs、errors。所以，跟其餘工具相比缺乏靈活性，可是若是你僅僅強制檢查代碼風格，JSCS也是一個好的工具。

優勢

• 支持自定義報告，更容易與其餘工具集成
• 若是你遵循一種可用的代碼風格，配置項和準備好的配置文件使其容易啓動
• 在報告中存在標記包含規則名字，因此很容易指出哪一個規則形成了錯誤
• 經過自定義插件進行拓展

缺點

• 僅僅檢查代碼風格的問題。JSCS不檢查潛在存在的bugs，例如不適用的變量、偶然的全局變量等等
• 四個工具中最慢，可是在使用中不是一個問題

ESLint

ESLint是最新出來的工具。它被設計的容易拓展、擁有大量的自定義規則、容易的經過插件來安裝。它給出準確的輸出，並且包括規則名，這樣能夠知道哪一個規則形成了錯誤。

ESLint文檔多少有些混亂。規則容易查找，以及被分爲邏輯組，可是配置指南在有些地方容易弄混。然而它能夠在一個地方提供連接去編輯集成、插件和樣例。

優勢

• 靈活：任何規則均可以開啓閉合，以及有些規則有些額外配置
• 很容易拓展和有須要可用插件
• 容易理解產出
• 包含了在其餘檢查器中不可用的規則，使得ESLint在錯誤檢查上更有用
• 支持ES6，惟一支持JSX的工具
• 支持自定義報告

缺點

• 須要一些配置
• 速度慢，但不是主要問題

個人推薦

個人選擇是ESLint。JSHint是嚴格和不可配置的，而JSHint缺乏拓展機制。JSCS若是僅僅用於代碼風格檢驗是一個好的選擇，可是ESLint不只能夠進行代碼風格的檢驗，並且能夠檢查代碼中的bug和其餘問題。

若是使用ES6，ESLint也是明顯的選擇。在上面提到的工具中，ESLint對ES6支持的最普遍。

若是你像嘗試ESLint，我已經創造了5步快速開始指南。你能夠 download the ESLint 5-step quickstart guide form my website

JSHint是第二選擇。若是不須要ESLint先進的特色，JSHint一旦配置就能夠捕獲須要好的問題。帶有許多規則的JSCS，若是出了代碼風格外不進行其餘檢查，將是一個好的選擇。

我很是猶豫去推薦JSLint。其餘工具作一樣地事情，可是不強制用戶遵照這些規則。惟一的例外是你碰巧統一那些強制規則，那是值得深刻研究的狀況。

一個檢驗工具是捕獲問題的很好一步，可是僅僅能看到它規則的錯誤。爲了更進一步的bug自動捕獲，我推薦使用單元測試。code view也有助於達到該目的。

你和你的團隊是如何保障代碼質量的呢？