1.no-debugger

一般來說，我們確實(shí)不希望代碼中出現(xiàn) debugger，但是，debugger 在項(xiàng)目的開發(fā)階段還是非常有用的，所以我們并沒有完全禁用這個(gè)關(guān)鍵字，而是采用了這樣的配置：

'no-debugger': process.env.NODE_ENV === 'production' ? 2 : 0

這樣一來，開發(fā)人員可以方便地使用 debugger 在本地進(jìn)行各種調(diào)試，同時(shí)有保證了線上代碼不會有忘記刪掉的 debugger

?

2.no-extra-boolean-cast

很多比較老的 javascript 代碼里面可以看到這樣的寫法：

var boolResult = !!parameter;

這里面實(shí)際上是做了一次隱式類型轉(zhuǎn)換，可是，你真的確切里面 js 隱式轉(zhuǎn)換的詳細(xì)規(guī)則么？事實(shí)上，在《javascript高級編程》一書里面，作者就明確警告了大家，盡量不要使用隱式類型轉(zhuǎn)換，因?yàn)檫@個(gè)轉(zhuǎn)換規(guī)則異常復(fù)雜，所以我們打開了這個(gè)規(guī)則，來避免潛在的問題

?

3.no-inner-declarations

ES6以前，函數(shù)聲明只能在程序或另一個(gè)函數(shù)體的最前面，所以在代碼塊內(nèi)部聲明函數(shù)是錯(cuò)誤的做法。另外，由于 javascript 中代碼聲明會被提升到代碼當(dāng)前作用域的最前面，所以在代碼塊內(nèi)聲明變量也是不明智的做法

?

4.use-isnan

這是很多人都容易忽略的一個(gè)點(diǎn)。javascript 代碼中 NaN 和任何變量作比較，都會得到 false，甚至和它自身比較都會得到false。所以，要判斷一個(gè)變量是否是 NaN 的時(shí)候，一定要用 isNaN 方法

?

5.eqeqeq

這一條可以說是每個(gè) javascript 開發(fā)人員都必需遵守的，禁用 == 和 != 用 === 和 !== 代替。原因和上面的第 2 條一樣，== 和 != 會帶來隱式的類型轉(zhuǎn)換，雖然 javascript 運(yùn)行時(shí)并不會轉(zhuǎn)換出錯(cuò)，但是后續(xù)維護(hù)代碼的人卻很可能理解錯(cuò)誤，所以這條規(guī)則是必備的

?

6.no-caller

這個(gè)規(guī)則的來由就比較復(fù)雜了，簡單來說，這是 ES6 之前的一個(gè) API，這個(gè) API 雖然幫我們解決了一些特殊場景的問題（匿名遞歸函數(shù)），但是，濫用這兩個(gè) API 會導(dǎo)致更多的問題，所以這個(gè) API 在 ES6 已經(jīng)被棄用了，在 ES5 的嚴(yán)格模式下也是被禁用的。如果你想詳細(xì)了解這個(gè) API 的用法，可以查看 MDN 上的詳細(xì)說明

?

7.no-extend-native

不要擴(kuò)展原生對象原型。當(dāng)你在某個(gè)對象上用 for in 語句遍歷對象屬性，而又忘了用 hasOwnProperty 判斷屬性來源的時(shí)候，你就會發(fā)現(xiàn)被你擴(kuò)展的原型屬性也會被遍歷出來，這往往都不是我們想要的結(jié)果

?

8.no-restricted-properties

這個(gè)規(guī)則事實(shí)上是一個(gè)工具，它可以禁用指定對象的指定方法。比如我們希望開發(fā)人員在發(fā) ajax 請求的時(shí)候，全部使用我們自己封裝的 ajax 方法，而不要使用 jQuery 的 ajax 方法，我們就可以通過這個(gè)配置，即使發(fā)現(xiàn)不符合我們規(guī)定的代碼

?

9.no-sequences

逗號表達(dá)式其實(shí)是我們比較常用的語法特性，比如在 for 循環(huán)中。不過它也有很多容易讓人犯錯(cuò)的用法，比如：

var a = 1, b = 1;

a = b += 3, a + b;

你知道這個(gè)時(shí)候 a 和 b 值分別是多少么？啟用此規(guī)則之后，你仍然可以在 for 循環(huán)和其它一些不容易出錯(cuò)的場景中使用逗號表達(dá)式，不過，如果 ESLint 提示你觸犯了規(guī)則，說明你就應(yīng)該修改你的代碼了。

另外，上面 a 和 b 的值都是 4

?

10.no-with

with 語句的作用是修改作用域鏈，雖然有時(shí)候可以用 with 語句來簡化代碼，比如：

with(frames[0].document.forms[1]){

? ? console.log(name.value); ? ?// 可直接訪問 form 里面的 name 屬性

}

但有時(shí)候 with 語句也會讓代碼難以理解，比如下面這段代碼里面，打印出來的 log 對象無法確認(rèn)是傳入的參數(shù)還是 obj 上面的屬性：

function f(log, obj) {

? ? with (obj) {

? ? ? ? console.log(log)

? ? }

}

所以，我們還是應(yīng)該盡量避免使用 with 語句

11.no-sparse-arrays

使用代碼質(zhì)量檢查工具的一個(gè)重要目的就是為了提高代碼的可讀性，或者說是降低其他人閱讀并理解代碼的難度，這條規(guī)則就是這樣。當(dāng)你看到這樣一段代碼 var userList = ['Tiger', 'Kate', , 'Mike']; 你真的很難確定原來寫這段代碼的人是不是故意要在數(shù)組中留下一個(gè) undefined 元素，畢竟這樣寫并沒有語法上的錯(cuò)誤。這條規(guī)則的目的就是禁止通過這種方式在數(shù)組中插入 undefined 元素，因?yàn)檫@種寫法太有迷惑性了。

?

12.no-extra-bind

如果你對 javascript 中的 this 變量有所了解，你一定也知道 bind 方法的作用，它可以很方便的幫我們修改方法執(zhí)行時(shí)的上下文環(huán)境，但事實(shí)上有些時(shí)候并不需要使用 bind。如果你在一些不需要使用 bind 的地方也用 bind 來保證方法執(zhí)行時(shí)的上下文環(huán)境，這會讓代碼執(zhí)行的效率變低。所以，啟用這條規(guī)則，可以幫你避免不必要的性能損失。

?

13.no-useless-call

和上一條規(guī)則類似，call 和 apply 也是幫助我們修改上下文環(huán)境的好工具，但我們應(yīng)該只在需要修改上下文的時(shí)候才去使用這兩個(gè)方法，如果你的代碼檢查工具發(fā)現(xiàn)你修改后的上下文和函數(shù)或方法原始的上下文相同，它就會給出提示。

?

14.yoda

yoda 表達(dá)式其實(shí)是用寫爭議的。有人覺得 if ('red' == color)? 這樣的寫法可以避免程序員不小心把 == 寫成了 =，但如前篇所說，我們用過在代碼中禁用 ==，一律換成 ===，同時(shí)在代碼檢查工具的幫助下，把 == 寫成 = 的可能性其實(shí)不大。而同時(shí)這樣的寫法在閱讀時(shí)也顯得比較別扭，所以我個(gè)人覺得還是禁用 yoda 表達(dá)式比較好。

?

15.no-delete-var

delete 操作符只能刪除對象上的屬性，并不能刪除當(dāng)前上下文中的某個(gè)變量，雖然代碼不會報(bào)錯(cuò)，但很可能實(shí)際運(yùn)行的結(jié)果和開發(fā)人員設(shè)想的不同，所以，應(yīng)該明確禁止刪除變量的操作。

?

16.no-undef

禁用未聲明的變量。javascript 異常靈活，以至于你可以在沒有聲明一個(gè)變量的時(shí)候直接給他賦值，比如 t = 'test message'，但這樣的寫法卻是非常危險(xiǎn)的，因?yàn)檫@種寫法雖然會自動生命變量 t，但他的作用域卻和用 var 聲明的變量作用域不同，t 變量的作用域在全局變量上，所以，不用 var 直接聲明并給變量賦值，經(jīng)常導(dǎo)致意料之外的程序 bug。

?

17.no-new-require

當(dāng)我們使用 CommonJS 的包管理規(guī)范時(shí)，經(jīng)常用 require 引入一些依賴，當(dāng)我們引入的依賴是一個(gè)類定義函數(shù)時(shí)，直接在 require 上進(jìn)行 new 操作很可能會引起誤解。比如 var tiger = new require('User'); 和 var tiger = new (require('User')); 所以，還是禁用這種寫法比較好。