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也有助於達到該目的。

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

javascript檢驗工具的比較