俗話說的好，無規矩不成方圓。
在團隊中，代碼規范的統一不僅能提高代碼質量，對代碼的維護者來說也是節省成本的事情。要知道在團隊中，我們平常寫代碼不能僅僅考慮到自己的感受，在業務的更替中，往往維護者也會更替。在業務的交接過程中如何降低交接成本也是很重要的事情，因為我們不可能總是甩手的人，大家往往也是另一個業務的接替者。
因此大家經常談到編碼規范的問題，並探討如何寫出靈活，穩定，高質量和可維護的代碼。長此以往也有很多同學總結了一些代碼規范，例：[http://codeguide.bootcss.com/],[http://www.alloyteam.com/2012/07/google-recommends-the-html5-code-specifications/],等等。希望以此來規范大家的編碼。
但效果可能並不明顯。在需求緊張，快速迭代的項目中，大家可能不會也沒有時間去遵守一些細節上的規范。這就使得編碼規范也就成了紙上談兵。
於是自動化的規范檢查和修改的一些工具也就應運而生了。像JSLint,CSS Lint和ESLint。
這里我們來看看ESLint。
一、什么是ESLint？
ESLint是鼎鼎大名的Nicholas C. Zakas發起的一個開源項目。一個用於識別和反饋代碼中模式錯誤的工具。
對於已有的JSLint,CSS Lint來說，ESLint向前走了幾步，這也是Nicholas C.Zakas想要在ESLint中解決的幾個問題：
1.單一的運行時環境；
JSHint 和 CSS Lint 都可以運行在 Rhino 和 Node.js中。聽起來好像挺不錯的樣子。但是事實上，要想在兩個環境中都良好的運行，要花的時間和測試的成本應該還是挺可觀的。
2.規則的開啟與禁用；
規則應該有明確的啟用和禁用的規則。並且需要有語義的提示。這一點在JSHint做的並不夠好。
3.文檔；
明確的文檔是開發者和使用者的小助手。JSLint 幾乎就沒有文檔，當然JSHint已經改進了些，但在遇到某些問題時還是常常求助無門。所以ESLint的文檔就相當的完善。
4.規則的配置；
在JSHint中，有些規則要配置true來啟用，但是有些卻需要配置false來啟用，經常會暈乎乎吧。
5.規則的優先級別；
在JSHint中只有error，也就是說你配置了規則，便要要個遵守，因為報了個錯嘛。CSS Lint中已經支持了warning，這樣更加人性化，因為如果因為空格和tab的沖突而讓代碼error而不能提交，顯得好無語。
6.編寫自己的規則；
這就是可擴展性，圍繞着ESLint，開發者可以根據自己的需求來開發適應自己業務的插件。
二、ESLint可以為我們做些什么？
1.開始使用ESLint
在我們的項目中使用ESLint只要三步：
1 1.npm install -g eslint; //安裝 2 2.eslint --init; //初始化項目，這會讓我們回答幾個問題，以自動生成初始eslint文件 3 3.eslint app.js //開始lint我們的文件
然后就可以在控制台中看到我們的warnings和errors了。
當然，面對一堆錯誤和警告，有的可能是分號的問題，有的可能是空格和tab的問題。這對於剛剛開始使用eslint的同學真的很頭疼，文件足夠大的話，修空格和tab就會讓人哭暈在廁所。
不要着急，通過自動fix一些問題，會減輕我們不少的工作量：
eslint app.js --fix
通過執行自動修復，可以把規則中可自動修復的規則（這里面的規則中后面括號中是fixable的）給修復掉。
自己試了下，解決了不少編碼風格上的問題。
2.ESLint的配置文件
在我們剛剛init的項目的時候，可以看到通過我們回答的問題，eslint會自動生成一個配置文件。
在eslint中，支持幾種格式的配置文件，包括：
1 .eslintrc.js 2 .eslintrc.yaml 3 .eslintrc.yml 4 .eslintrc.json 5 .eslintrc
當一個項目中有多個種類后綴的eslintrc文件時，也只會讀取其中一種，優先級就是按照上面的順序。
其實，我們可以在這里看到ESLint支持的所有規則。下面我們從一個簡單的配置文件看下規則的配置。
這是上面我在自己的一個項目中生成的eslint文件[.eslintrc.js]：
1 module.exports = { 2 "rules": { 3 "indent": [ 4 2, 5 "tab" 6 ], 7 "quotes": [ 8 2, 9 "single" 10 ], 11 "linebreak-style": [ 12 2, 13 "unix" 14 ], 15 "semi": [ 16 2, 17 "always" 18 ], 19 // http://eslint.org/docs/rules/no-native-reassign 20 // 不允許 native 變量被重置 21 "no-native-reassign": 1, 22 // http://eslint.org/docs/rules/no-return-assign 23 // 是否允許 return 返回表達式 24 "no-return-assign": 1, 25 // http://eslint.org/docs/rules/no-constant-condition 26 "no-constant-condition": 1, 27 }, 28 "globals": { 29 "KISSY": true, 30 "$": true, 31 "require": true, 32 "module": true 33 }, 34 "env": { 35 "es6": true, 36 "browser": true 37 }, 38 "extends": "eslint:recommended", 39 "ecmaFeatures": { 40 "jsx": true, 41 "experimentalObjectRestSpread": true 42 }, 43 "plugins": [ 44 "react" 45 ] 46 };
這里一些關鍵配置的含義大概是這樣的：
1 "extends": "eslint:recommended"
eslint有一些推薦的規則，用來捕捉一些比較通用的問題和錯誤，在后面括號中有recommended字樣的規則。在配置文件中做上面這個配置，就說明這些推薦的規則全部開啟。
1 "env": { 2 "es6": true, 3 "browser": true 4 },
這條配置用於高速eslint你的代碼在那個環境中運行。每個環境帶有自己一系列的預定義的全局變量。
1 "globals": { 2 "KISSY": true, 3 "$": true, 4 "require": true, 5 "module": true 6 },
用來添加在代碼運行時我們允許的額外的全局變量。對全局變量進行約束。
1 "plugins": [ 2 "react" 3 ]
eslint允許使用第三方的變量，我們可以配置在這里。
1 "ecmaFeatures": { 2 "jsx": true, 3 "experimentalObjectRestSpread": true 4 },
eslint允許我們選擇性的使用js語言的某些特性。可以通過ecmaFeatures來配置
三、小結
紙上談兵的事情，總是不容易引起注意。
盡管我們可能為了項目的規范制定了一些規則希望大家遵守，但是主觀意義上的約束實際上並不靠譜。
借助一些自動化的工具，集成到我們的開發環境中去，是一個不錯的選擇。
雖然剛剛開始的時候會有些陣痛，但長遠來看還是比較有價值的。