JavaScript程式碼檢查工具對比

發表於2017-07-25

看到很多團隊和開源專案都在用程式碼檢查工具,自己一直沒用過,最近加入了新團隊有專案在用,就想著研究一下。看到sitepoint上的一篇2015年的文章覺得不錯就給翻譯出來了。本文譯自A Comparison of JavaScript Linting Tools,本文由 @Darko 翻譯,轉載請保留原文連結。

JavaScript程式碼校驗工具能夠讓你在寫程式碼時避免一些低階的錯誤。儘管我有很多年的開發經驗,我仍然會犯一些語法錯誤並且忘記處理我的錯誤。一個好的校驗工具或者格式化工具,可以讓我避免這些錯誤,以免浪費我的時間(甚至是我客戶的時間)。一個好的校驗工具還能確保一個專案保持一個固定的程式碼風格。

有很多關於JavaScript的校驗工具,你怎樣選擇其中的某一個呢?讓我們一起來看看它們有什麼樣的特性以及優缺點。接下來我要介紹四種常用的選擇:JSLintJSHintJSCSESLint

Overview

這四個工具的基本用法都是類似的,它們定義了一套規則用來解析和報告js檔案裡面的問題。它們都可以通過npm來進行安裝。可以通過命令列來呼叫它們,給命令列傳遞檔案引數,也可以作為grunt這一類工具的外掛被使用,或者可以整合到編輯器中。它們都支援使用註釋作為配置。

以上就是它們所有的相似之處了,每一個工具都有優缺點,只是有些工具相比於其它工具更加有優勢。

JSLint

JSLint是這四種校驗工具中最為古老的。Douglas Crockford(譯註:《JavaScript 語言精粹》的作者)在2002年創造了它,它是強制使用的,為了保留它所認為的JavaScript這門語言的精華部分。如果你認同他的觀點,對你而言,JSLint將會是一個好的工具。安裝完成馬上即可使用。

JSLint的缺點是它是不可以進行配置和擴充套件的。你不能禁用它的某些特性,並且缺乏文件。它的官網並沒有什麼用處,例如,它缺少如果將這個工具整合到你的編輯器的任何資訊。

bVRel4

 

優點:

  • 配置規則都已經定好了,安裝即可使用(如果你同意這些強制的規則的話)

缺點:

  • JSLint沒有可配置檔案,你無法對它的規則進行更改
  • 配置規則的數量有限,有些規則無法禁用
  • 不支援自定義規則
  • 缺少文件
  • 很難定位到哪條規則導致了錯誤

JSHint

JSHint是JSLint的一個更加靈活,可配置的一個版本,它從JSLint中fork出來。你能夠自己配置每一條規則,並且把他們寫到一個配置檔案裡,這讓JSHint更易於在大型專案中使用。同時,JSHint也有友好的文件針對每一條規則。所以能夠準確的知道它做了些什麼。把它整合到編輯器中也是很簡單的一件事。

JSHint的一個小缺點就是,它的預設配置是非常輕量級的。這就意味著你要做一些設定才能使其變得有用。和ESLint相比,為了啟用或者禁用某些錯誤的報告,要知道需要修改哪些規則也是比較困難的。bVRd01

 

優點:

  • 大多數設定都是可配置的
  • 支援配置檔案,更易於在大型專案中使用
  • 支援很多第三方庫或和框架,例如jqery,QUnit,NodeJs,Mocha等等
  • 支援基本的ES語法

缺點:

  • 很難定位到哪條規則造成了錯誤
  • 有兩種型別的配置:強制執行的和比較鬆散的,這讓配置變得有些混亂
  • 不支援自定義規則

JSCS

JSCS和以上兩個都是不同的,如果不給它一個配置檔案或者使用一套預設的規則,它將什麼也不做不了,不過你可以從別的網站下載配置檔案,所以這並不是什麼大問題,並且它有很多的預設規則,比如說jQuery的程式碼風格的預設規則以及Google的程式碼風格的預設規則。

它有超過90種不同的規則,並且你可以通過外掛創造自定義規則。JSCS也支援自定義輸出報告,這使得其更容易與需要其以特定格式輸入的工具整合。

JSCS是一個程式碼風格檢查器,這意味著它只捕獲與程式碼格式相關的問題,而不包含潛在的錯誤。因此,它比其他工具的靈活性更低,但是如果您需要強制執行特定的編碼風格,那麼JSCS就可以做的很好。

bVRemj

 

優點:

  • 支援自定義輸出報告,可以使其更容易和其它工具進行整合
  • 如果您遵循現有的可用編碼風格之一,預設和現成的配置檔案可以輕鬆設定
  • 在報告中,有一個標誌包含在規則名之中,所以很容易找出是哪條規則導致了錯誤
  • 可以利用自定義的外掛進行擴充

缺點:

  • 只檢測到程式碼風格的違規,不檢測潛在的錯誤,比如說未使用的變數或者變數的全域性汙染等
  • 四個工具中效能最差的,但是這並不是一個典型用途的問題

ESLint

ESLint是這四個工具中最新的,它被設計為易於擴充的,具有大量的自定義規則,並且很容易通過外掛的形式來安裝。它輸出簡潔的報告,但是預設包含規則的名稱,因此你始終知道是那條規則導致了錯誤的資訊。

ESLint的文件多少有些混亂,規則的列表容易查詢,並且按邏輯進行分類,但配置說明在某些地方有點混亂。然而,它提供瞭如何對編輯器進行整合,外掛和示例的連結。

bVReml

 

優點:

  • 靈活:任何規則都可以切換使用,並且有些規則有額外的配置可以使用
  • 可擴充性好,並且有很多可用的外掛
  • 易於理解的輸出報告
  • 包含一些其它工具所沒有的規則,使得ESLint更容易檢測出程式碼中潛在的錯誤
  • 對ES6的支援性最好,是唯一支援JSX的工具
  • 支援自定義輸出報告

缺點:

  • 需要一些配置
  • 效能差,但這並不是主要的障礙

推薦

在這四個工具中,我選擇了ESLint,JSLint太嚴格並且不可配置,而JSHint缺乏擴充套件機制。如果您只想檢查編碼風格,則JSCS是一個不錯的選擇,但是ESLint也可以這樣做,並且它會檢查程式碼中的錯誤和其他問題。

如果你想使用ES6的話,ESLint也是顯而易見的選擇。在上文提高的所有工具當中它對ES6有著最好的支援。

JSHint是第二好的選擇,如果你不需要ESLint的那些高階特性的話。一旦被正確的配置,JSHint可以捕捉到大量的問題。JSCS有大量可用的規則,如果你不需要編碼樣式檢查(縮排、括號等)以外的任何事情,那麼它就是首選。

對於JSLint,我很猶豫要不要推薦它,其它的工具可以做到和他同樣的事情但是不會強制要求使用者去使用特定的規則。如果你正巧非常同意它的哪些強制規則,那麼也許值得好好去了解一下。

一個好的校驗工具是捕捉問題非常重要的一步,但是它只能檢測出它的規則許可範圍之內的錯誤。對於更多簡單明瞭的bug的捕捉,我建議使用單元測試,Code reviews也是也是不錯的方式。

你和你的團隊是如果保證程式碼質量的呢?可以在評論區留言。

相關文章