前端界大神 Nicholas C. Zakas 在 2013 年開發的 ESLint，極大地方便了大家對 Javascript 代碼進行代碼規范檢查。這個工具包含了 200 多條 Javascript 編碼規范且運行迅速，是幾乎每個前端項目都必備的輔助工具。可是，這么多規則，每個規則的設計出發點是什么，我們該如何選擇適合自己項目的規則，又成了新問題。前不久，我所在的項目開始對前端代碼進行代碼規范的要求，于是我們詳細梳理了 eslint 中的 230 個規則。我摘錄了其中一些比較重要或特別的規則列在這里，希望能對大家的工作有所幫助。
-
1.no-debugger
一般來說，我們確實不希望代碼中出現 debugger，但是，debugger 在項目的開發階段還是非常有用的，所以我們并沒有完全禁用這個關鍵字，而是采用了這樣的配置：
'no-debugger': process.env.NODE_ENV === 'production' ? 2 : 0
這樣一來，開發人員可以方便地使用 debugger 在本地進行各種調試，同時有保證了線上代碼不會有忘記刪掉的 debugger
?
-
2.no-extra-boolean-cast
很多比較老的 javascript 代碼里面可以看到這樣的寫法：
var boolResult = !!parameter;
這里面實際上是做了一次隱式類型轉換，可是，你真的確切里面 js 隱式轉換的詳細規則么？事實上，在《javascript高級編程》一書里面，作者就明確警告了大家，盡量不要使用隱式類型轉換，因為這個轉換規則異常復雜，所以我們打開了這個規則，來避免潛在的問題
?
-
3.no-inner-declarations
ES6以前，函數聲明只能在程序或另一個函數體的最前面，所以在代碼塊內部聲明函數是錯誤的做法。另外，由于 javascript 中代碼聲明會被提升到代碼當前作用域的最前面，所以在代碼塊內聲明變量也是不明智的做法
?
-
4.use-isnan
這是很多人都容易忽略的一個點。javascript 代碼中 NaN 和任何變量作比較，都會得到 false，甚至和它自身比較都會得到false。所以，要判斷一個變量是否是 NaN 的時候，一定要用 isNaN 方法
?
-
5.eqeqeq
這一條可以說是每個 javascript 開發人員都必需遵守的，禁用 == 和 != 用 === 和 !== 代替。原因和上面的第 2 條一樣，== 和 != 會帶來隱式的類型轉換，雖然 javascript 運行時并不會轉換出錯，但是后續維護代碼的人卻很可能理解錯誤，所以這條規則是必備的
?
-
6.no-caller
這個規則的來由就比較復雜了，簡單來說，這是 ES6 之前的一個 API，這個 API 雖然幫我們解決了一些特殊場景的問題（匿名遞歸函數），但是，濫用這兩個 API 會導致更多的問題，所以這個 API 在 ES6 已經被棄用了，在 ES5 的嚴格模式下也是被禁用的。如果你想詳細了解這個 API 的用法，可以查看 MDN 上的詳細說明
?
-
7.no-extend-native
不要擴展原生對象原型。當你在某個對象上用 for in 語句遍歷對象屬性，而又忘了用 hasOwnProperty 判斷屬性來源的時候，你就會發現被你擴展的原型屬性也會被遍歷出來，這往往都不是我們想要的結果
?
-
8.no-restricted-properties
這個規則事實上是一個工具，它可以禁用指定對象的指定方法。比如我們希望開發人員在發 ajax 請求的時候，全部使用我們自己封裝的 ajax 方法，而不要使用 jQuery 的 ajax 方法，我們就可以通過這個配置，即使發現不符合我們規定的代碼
?
-
9.no-sequences
逗號表達式其實是我們比較常用的語法特性，比如在 for 循環中。不過它也有很多容易讓人犯錯的用法，比如：
var a = 1, b = 1;
a = b += 3, a + b;
你知道這個時候 a 和 b 值分別是多少么？啟用此規則之后，你仍然可以在 for 循環和其它一些不容易出錯的場景中使用逗號表達式，不過，如果 ESLint 提示你觸犯了規則，說明你就應該修改你的代碼了。
另外，上面 a 和 b 的值都是 4
?
-
10.no-with
with 語句的作用是修改作用域鏈，雖然有時候可以用 with 語句來簡化代碼，比如：
with(frames[0].document.forms[1]){
? ? console.log(name.value); ? ?// 可直接訪問 form 里面的 name 屬性
}
但有時候 with 語句也會讓代碼難以理解，比如下面這段代碼里面，打印出來的 log 對象無法確認是傳入的參數還是 obj 上面的屬性：
function f(log, obj) {
? ? with (obj) {
? ? ? ? console.log(log)
? ? }
}
所以，我們還是應該盡量避免使用 with 語句
?
-
11.no-sparse-arrays
使用代碼質量檢查工具的一個重要目的就是為了提高代碼的可讀性，或者說是降低其他人閱讀并理解代碼的難度，這條規則就是這樣。當你看到這樣一段代碼 var userList = ['Tiger', 'Kate', , 'Mike']; 你真的很難確定原來寫這段代碼的人是不是故意要在數組中留下一個 undefined 元素，畢竟這樣寫并沒有語法上的錯誤。這條規則的目的就是禁止通過這種方式在數組中插入 undefined 元素，因為這種寫法太有迷惑性了。
?
-
12.no-extra-bind
如果你對 javascript 中的 this 變量有所了解，你一定也知道 bind 方法的作用，它可以很方便的幫我們修改方法執行時的上下文環境，但事實上有些時候并不需要使用 bind。如果你在一些不需要使用 bind 的地方也用 bind 來保證方法執行時的上下文環境，這會讓代碼執行的效率變低。所以，啟用這條規則，可以幫你避免不必要的性能損失。
?
-
13.no-useless-call
和上一條規則類似，call 和 apply 也是幫助我們修改上下文環境的好工具，但我們應該只在需要修改上下文的時候才去使用這兩個方法，如果你的代碼檢查工具發現你修改后的上下文和函數或方法原始的上下文相同，它就會給出提示。
?
-
14.yoda
yoda 表達式其實是用寫爭議的。有人覺得 if ('red' == color)? 這樣的寫法可以避免程序員不小心把 == 寫成了 =，但如前篇所說，我們用過在代碼中禁用 ==，一律換成 ===，同時在代碼檢查工具的幫助下，把 == 寫成 = 的可能性其實不大。而同時這樣的寫法在閱讀時也顯得比較別扭，所以我個人覺得還是禁用 yoda 表達式比較好。
?
-
15.no-delete-var
delete 操作符只能刪除對象上的屬性，并不能刪除當前上下文中的某個變量，雖然代碼不會報錯，但很可能實際運行的結果和開發人員設想的不同，所以，應該明確禁止刪除變量的操作。
?
-
16.no-undef
禁用未聲明的變量。javascript 異常靈活，以至于你可以在沒有聲明一個變量的時候直接給他賦值，比如 t = 'test message'，但這樣的寫法卻是非常危險的，因為這種寫法雖然會自動生命變量 t，但他的作用域卻和用 var 聲明的變量作用域不同，t 變量的作用域在全局變量上，所以，不用 var 直接聲明并給變量賦值，經常導致意料之外的程序 bug。
?
-
17.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
?
)
 是否相等)
)模版引擎之基礎入門 C#中文本模板(.tt)的應用...)
