ESLint 規則詳解（二）

 

接上篇 ESLint 規則詳解（一）

前端界大神 Nicholas C. Zakas 在 2013 年開發的 ESLint，極大地方便了你們對 Javascript 代碼進行代碼規範檢查。這個工具包含了 200 多條 Javascript 編碼規範且運行迅速，是幾乎每一個前端項目都必備的輔助工具。但是，這麼多規則，每一個規則的設計出發點是什麼，咱們該如何選擇適合本身項目的規則，又成了新問題。前不久，我所在的項目開始對前端代碼進行代碼規範的要求，因而咱們詳細梳理了 eslint 中的 230 個規則。我摘錄了其中一些比較重要或特別的規則列在這裏，但願能對你們的工做有所幫助。

 

1. no-sparse-arrays

   使用代碼質量檢查工具的一個重要目的就是爲了提升代碼的可讀性，或者說是下降其餘人閱讀並理解代碼的難度，這條規則就是這樣。當你看到這樣一段代碼 var userList = ['Tiger', 'Kate', , 'Mike']; 你真的很難肯定原來寫這段代碼的人是否是故意要在數組中留下一個 undefined 元素，畢竟這樣寫並無語法上的錯誤。這條規則的目的就是禁止經過這種方式在數組中插入 undefined 元素，由於這種寫法太有迷惑性了。

    

2. no-extra-bind

   若是你對 javascript 中的 this 變量有所瞭解，你必定也知道 bind 方法的做用，它能夠很方便的幫咱們修改方法執行時的上下文環境，但事實上有些時候並不須要使用 bind。若是你在一些不須要使用 bind 的地方也用 bind 來保證方法執行時的上下文環境，這會讓代碼執行的效率變低。因此，啓用這條規則，能夠幫你避免沒必要要的性能損失。

    

3. no-useless-call

   和上一條規則相似，call 和 apply 也是幫助咱們修改上下文環境的好工具，但咱們應該只在須要修改上下文的時候纔去使用這兩個方法，若是你的代碼檢查工具發現你修改後的上下文和函數或方法原始的上下文相同，它就會給出提示。

    

4. yoda

   yoda 表達式實際上是用寫爭議的。有人以爲 if ('red' == color)  這樣的寫法能夠避免程序員不當心把 == 寫成了 =，但如前篇所說，咱們用過在代碼中禁用 ==，一概換成 ===，同時在代碼檢查工具的幫助下，把 == 寫成 = 的可能性其實不大。而同時這樣的寫法在閱讀時也顯得比較彆扭，因此我我的以爲仍是禁用 yoda 表達式比較好。

    

5. no-delete-var

   delete 操做符只能刪除對象上的屬性，並不能刪除當前上下文中的某個變量，雖然代碼不會報錯，但極可能實際運行的結果和開發人員設想的不一樣，因此，應該明確禁止刪除變量的操做。

    

6. no-undef

   禁用未聲明的變量。javascript 異常靈活，以致於你能夠在沒有聲明一個變量的時候直接給他賦值，好比 t = 'test message'，但這樣的寫法倒是很是危險的，由於這種寫法雖然會自動生命變量 t，但他的做用域卻和用 var 聲明的變量做用域不一樣，t 變量的做用域在全局變量上，因此，不用 var 直接聲明並給變量賦值，常常致使意料以外的程序 bug。

    

7. no-new-require

   當咱們使用 CommonJS 的包管理規範時，常常用 require 引入一些依賴，當咱們引入的依賴是一個類定義函數時，直接在 require 上進行 new 操做極可能會引發誤解。好比 var tiger = new require('User'); 和 var tiger = new (require('User')); 因此，仍是禁用這種寫法比較好。

 

最後附上 ESLint 規則列表，詳細列出了每條規則的名稱，官方是否推薦開啓，以及每條規則是否可以用 --fix 參數自動修復。 點擊下載

 

如需轉載，請註明轉自：http://www.cnblogs.com/silenttiger/p/6855604.html

 

歡迎關注個人微信公衆號：老虎的小窩