如何改善既有 JS 程式碼：修復常見的 ESLint 報警（四）
摘要：
前言
ESLint 是目前最主流、最強大的 JS 程式碼校驗工具。當我們的程式碼觸發了 ESLint 的報警規則時，ESLint 就會提示錯誤。
本系列文章將詳細講解那些需要手工介入修復的 ESLint 規則，幫助你順利地把既有程式碼遷移到 ESLint 的保護之中。
...
前言
ESLint 是目前最主流、最強大的 JS 程式碼校驗工具。當我們的程式碼觸發了 ESLint 的報警規則時，ESLint 就會提示錯誤。
本系列文章將詳細講解那些需要手工介入修復的 ESLint 規則，幫助你順利地把既有程式碼遷移到 ESLint 的保護之中。
no-fallthrough
禁止在 switch / case 語句中使用穿透特性。
我們在 JS（以及大多數類 C 語言）裡寫 switch/case 往往會踩的一個坑就是 “穿透”。簡單解釋一下，在 swithc 的執行過程中，匹配了一個 case 並執行完這個 case 的程式碼之後，如果沒有遇到 break 語句，則會繼續執行 後續所有 case 的程式碼。
這是一個非常反直覺的設計，也是 bug 的溫床。因此 ESLint 提供了 no-fallthrough 這條規則，避免無意中踩到穿透特性的坑。
但如果在某些場景下，你真的需要這個特性怎麼辦？ESLint 允許你通過註釋來說明你是真的在利用穿透特性，只要註釋符合特定格式就可以抑制報警：
switch (foobar) {
case 1:
doSomething()
// fall through
case 2:
doSomethingElse()
}
no-undef
禁止使用未定義的變數。
當我們在使用一個變數之前忘了宣告它，這條規則就會報警提醒我們。不過大多數觸發報警的程式碼是在引用一個全域性變數，而 ESLint 並未理解。
比如有以下程式碼：
// namespace
window.Auth = { /* ... */ }
// ...
// init
if (page && Auth[page]) {
Auth[page]()
}
在後面這個 if 語句中有對 Auth 的引用。雖然我們在第一行已經定義了 Auth 這個全域性變數（ window.Auth = ... ），但 ESLint 無法識別，這條規則會報警。
有兩種方式可以修復這個問題…………
……
……
© Creative Commons BY-NC-ND 4.0 | ofollow,noindex" target="_blank">我要訂閱 | 我要打賞