eslint使用心得

eslint可以配置在開發環境中，幫助我們找出項目中不符合規則的代碼并給出提示。在我們的開發環境中，開發者每次修改代碼，都會先用eslint檢查代碼，再進行babel和react的編譯，一旦eslint發現error級别的錯誤，那麼報錯檔案不會進行後續的編譯。這樣可以讓eslint随時提醒開發者代碼是否符合規範，進而減少了我們花費在review代碼風格上的時間，降低了低級bug的出現。

同類型的代碼檢查工具還有jslint和jshint，和它們相比，eslint對es6文法支援更好，這是我們選擇使用eslint的主要原因之一，可以通過eslint在團隊内快速統一es6的文法，精簡産品代碼，提高開發效率。

規則格式是"<規則名稱>: <告警級别>"，告警級别分為三種:

"0"表示忽略問題，等同于"off";

"1"表示給出警告，等同于"warn";

"2"表示直接報錯，等同于"error"。

配置4個空格一個縮進，不符合配置時報錯：

或者，switch下的case縮進4個空格，不符合配置時警告：

引入并配置好eslint和eslint-loader後，就可以開始添加webpack的相關配置了：

讓webpack在打封包件之前，對除第三方外的js檔案用eslint進行檢查。

完成上述配置後，webpack在建構時就能自動對js代碼用eslint進行檢查了。

注：由于webpack在預設配置下遇到error并不會抛出錯誤終止代碼打包，需要在webpack指令上添加bail參數讓webpack抛出錯誤：

如果需要react和jsx的文法檢查，可以引入eslint-plugin-jsx-a11y和eslint-plugin-react這兩個插件并在.eslintrc檔案中添加入plugins的配置：

規則格式是"<插件名稱>/<規則名稱>: <告警級别>"：

除了支援插件外，eslint還支援通過擴充來快速的引入開源的javascript代碼規則，減少了我們選擇規則的時間，例如eslint官方推薦的規則：

如果擴充引入的有些規則不符合所在團隊的開發習慣，可在.eslintrc的rules中用自己的配置覆寫掉擴充中的預設值。

引入擴充的目的是減少我們挑選規則的時間，但這些規則不一定切合團隊和項目的具體情況。如果一味地讓團隊去遵守别人制定的規則，很可能造成對現存代碼的大範圍修改，反而降低了開發效率。是以，建議先依據團隊現有的良好的風格挑選出最符合現有開發習慣的規則，保證已有的好習慣不被破壞的基礎上，再添加一些希望在團隊中推廣的規則。

javascript是一種很靈活的語言，一些筆誤或者多餘的寫法并不會引起代碼編譯打包報錯，卻會留下風格不良或實作錯誤的代碼。我們選取了下面兩條規則來自動定位這些問題代碼:

javascript的判斷語句會自動将一個任意類型的值轉成boolean類型，但我們有時會看到如下代碼：

這種類型轉換都是多餘的，因為判斷本身就會幫你做這步操作，是以我們選取了這個規則，并設定為error級别：

上面我們說過javascript在條件判斷時，會把任何類型的值都轉成boolean，是以如果我們代碼中出現了如下筆誤：

這是一個bug, 但javascript引擎卻不會報錯，是以我們把這條規則也設定為error級别:

代碼可讀性是團隊開發中極為重要的一環，可讀性高的代碼能減少溝通成本并讓代碼更容易重構。我們選取了下面兩條規則來提高代碼可讀性：

magic number特指我們代碼中出現的含義不明确的數字，如下面這段代碼中的199,0.8和0.79：

上面代碼的意思是，對于購物金額超過199的部分享8折優惠，vip使用者可以對最終金額享受7.9折優惠。

但是這種寫法的代碼可讀性差，在不了解業務需求的情況下很難了解其中涵義，我們為這種代碼選擇了直接報錯的配置:

上面的代碼需要改為下面的版本才能通過檢查

将意義不明的數字聲明為意義明确的常量，常量名稱能讓代碼自注釋，進而提高了代碼的可讀性，并且由于數字僅出現一次，修改也更容易。

但是，我們發現引入這條規則之後，多處代碼報錯no-magic-number:

這明顯是不符合我們期望的，但eslint中支援配置哪些數字不被視為magic number并忽略對數組下标的檢查：

0，1兩個數字以及數組下标都不會被當成magic number。

最後，我們還規定這類數字必須使用es6的const聲明為常量：

在實際開發中，代碼會随着需求的變化而變化，比如一個顯示彈出框的方法：

最初隻需要控制彈出框的标題和内容，showdialog()方法也就隻有兩個參數，簡單明了。後來需要控制彈出框的位置、大小以及遮罩的顯示，代碼變成了這樣：

這時代碼變得難以閱讀，而且在調用的時候需要記住每個參數的位置，很不友善。通過max-params規則：

要求建立的方法中參數不能超過4個後，上面的代碼必須改寫為下面的版本才能通過檢查：

将所有的參數配置包含在一個object類型的參數中，增強了代碼的靈活性和可讀性。

盡管我們的項目中很早就引入了es6，但是代碼中依然存在大量es5和es6的文法混用。我們選取了下面幾條規則來推廣es6的使用：

es6的let關鍵字解決了var關鍵字無法實作塊作用域的問題；const關鍵字解決了var關鍵字無法定義常量的問題。通過規則:

禁用var關鍵字後，代碼必須根據不同場合選用let或const替代var。

javascript程式設計離不開回調函數，但回調函數常常會遇到this引用的指向問題。在es5中，雖然可通過重新給this指派:

或改變this綁定對象：

這兩種方式來解決這個問題，但代碼卻顯得不夠簡潔美觀，而在es6中則提供了箭頭回調函數這一更簡潔的方式：

es6的箭頭回調函數标記法"()=>{}"等同于es5中的"function (){}.bind(this)"。因為項目的已有代碼中這種用法過多，大範圍修改工作量較大，對于這個用法我們隻設定了警告規則提醒開發者注意，并不要求強制修改：

早期的javascript項目中拼接html字元串的做法十分常見：

通過規則：

将字元串的拼接操作統一為es6的模闆操作。