一千個(gè)讀者，就有一千個(gè)哈姆雷特。

一千個(gè)程序員，就有一千種代碼風(fēng)格。

那什么是代碼風(fēng)格呢?從小的來說，有的開發(fā)喜歡帶分號(hào)，有的不喜歡帶分號(hào)。有的喜歡使用空格，有的喜歡使用 Tab。有的喜歡空兩個(gè)空格，有的喜歡四個(gè)空格。除了這些，還有一些關(guān)于代碼的優(yōu)化，如避免聲明未使用，避免冗余的代碼邏輯等。如果你是新參加工作的人員，又恰好遇到一個(gè)代碼風(fēng)格混亂，密密麻麻賦值前后都不帶空格的項(xiàng)目，只能有苦難言了。

因此團(tuán)隊(duì)合作中需要統(tǒng)一規(guī)范。

ESLint 與約束

統(tǒng)一編碼規(guī)范不僅可以大幅提高代碼可讀性，甚至?xí)岣叽a質(zhì)量。當(dāng)我們?cè)O(shè)計(jì)了一套關(guān)于編碼規(guī)范的規(guī)則集時(shí)，需要工具去輔助檢測(cè)，這就是 ESLint。

$ npm install eslint --save-dev 

規(guī)則集需要統(tǒng)一集中配置，ESLint 會(huì)默認(rèn)讀取配置文件 .eslintrc 來解析，而規(guī)則集在 rules 中進(jìn)行配置：

{ 
  "rules": { 
    "semi": ["error", "always"], 
    "quotes": ["error", "double"] 
  } 
} 

而我們需要做的是設(shè)定我們的代碼規(guī)范，即 rules 項(xiàng)。

不要重復(fù)造輪子

我們需要推到重來，設(shè)計(jì)屬于自己團(tuán)隊(duì)的一套編碼規(guī)范嗎?

完全沒有必要推倒重來，既耗費(fèi)人力，又難以做到規(guī)則的全部覆蓋。

很多優(yōu)秀的團(tuán)隊(duì)，都根據(jù)最佳實(shí)踐設(shè)定了特別優(yōu)秀的編碼規(guī)范，比如 airbnb 設(shè)定了一套約束特別強(qiáng)的規(guī)范。另外也有一些特別簡(jiǎn)單但卻十分實(shí)用的規(guī)范，如 eslint:recommended。

airbnb javascript style[2]

我們僅僅需要使用 extend 配置項(xiàng)去繼承一些優(yōu)秀的開源的代碼規(guī)范，并使用 rules 做一些自己團(tuán)隊(duì)的規(guī)則補(bǔ)充。

{ 
  "extend": ["airbnb-base"], 
  "rules": { 
    "semi": ["error", "never"] 
  } 
} 

開發(fā)環(huán)境，生產(chǎn)環(huán)境與警告

開發(fā)環(huán)境對(duì)于開發(fā)而言重要的是什么?

是開發(fā)體驗(yàn)。

一個(gè)良好的編碼規(guī)范會(huì)帶來解放強(qiáng)迫癥的舒適感，但過于嚴(yán)格的代碼風(fēng)格有時(shí)也會(huì)使人煩躁。試舉兩個(gè)小例子，有可能是在你寫代碼時(shí)出現(xiàn)過的場(chǎng)景：

• 禁止掉 console.log，避免在生產(chǎn)環(huán)境輸出多余的東西。但偏偏在測(cè)試環(huán)境經(jīng)常需要調(diào)試，但是如果僅僅設(shè)為警告的話，警告又會(huì)被忽視，失去意義。
• 特別是當(dāng)設(shè)置了規(guī)則 no-unused-vars 時(shí)。如果僅僅是為了在開發(fā)時(shí)調(diào)試，卻因?yàn)闊o法通過 ESlint 規(guī)則校驗(yàn)無法方便調(diào)試。

這是一個(gè)約束與自由的權(quán)衡，ESLint 在提供強(qiáng)有力約束時(shí)自然會(huì)犧牲一些開發(fā)上的便利性。中庸，儒家思想講究中庸，此時(shí)可以在權(quán)衡下選擇一個(gè)中庸的方案：

把 ESLint 的所有影響調(diào)試的規(guī)則校驗(yàn)都設(shè)置為 Warn，那你又問了警告往往不是會(huì)被忽略嗎?是這樣子的，所以需要在 CI 中設(shè)置環(huán)境變量 CI=true，如此在 CI 中即使有警告也無法交付。

如在 create-react-app 中的大部分規(guī)則都是設(shè)置為 Warn

但是，如果你使用了 webpack，并且結(jié)合 eslint-loader，那解決方案就更加簡(jiǎn)單了：使用 emitWarning: true，在測(cè)試環(huán)境把所有 Error 都當(dāng)做 Warn，這樣避免了修改 ESLint 規(guī)則，webpack 的配置如下：

{ 
  test: /\.(js|mjs|jsx|ts|tsx)$/, 
  enforce: 'pre', 
  use: [ 
    { 
      options: { 
        cache: true, 
        emitWarning: true, 
      }, 
      loader: require.resolve('eslint-loader'), 
    }, 
  ] 
} 

所以有兩種權(quán)衡開發(fā)體驗(yàn)與編程規(guī)范的方式：

• 把 ESLint 的 rule 設(shè)置為 Warn，并在持續(xù)集成中配置環(huán)境變量 CI=true。
• 結(jié)合 webpack 與 eslint-loader，根據(jù)當(dāng)前環(huán)境的環(huán)境變量配置 emitWarning。

第一層約束：IDE

當(dāng)不符合代碼規(guī)范的第一時(shí)間，我們就要感知到它，及時(shí)反饋，快速糾正，比直到最后積攢了一大堆錯(cuò)誤要高效很多。

這里以 VS Code 作為示例，它只需要安裝一個(gè)插件：eslint，便可以做到智能提示，來看看效果吧：

另外，配合 eslint-loader，使用瀏覽器也可以做到實(shí)時(shí)提示：

第二層約束：Git Hooks

團(tuán)隊(duì)合作中的編碼規(guī)范有一點(diǎn)是，雖然自己有可能不舒服，但是不能讓別人因?yàn)樽约旱拇a而不舒服。

git 自身包含許多 hooks，在 commit，push 等 git 事件前后觸發(fā)執(zhí)行。與 pre-commit hook 結(jié)合可以幫助校驗(yàn) Lint，如果非通過代碼規(guī)范則不允許提交。

husky[3] 是一個(gè)使 git hooks 變得更簡(jiǎn)單的工具，只需要配置幾行 package.json 就可以愉快的開始工作。

(1) husky 的原理是什么?

// package.json 
{ 
  "scripts": { 
    "lint": "eslint . --cache" 
  }, 
  "husky": { 
    "hooks": { 
      "pre-commit": "npm lint", 
    } 
  } 
} 

或者結(jié)合 lint-staged[4] 調(diào)用校驗(yàn)規(guī)則

{ 
  "husky": { 
    "hooks": { 
      "pre-commit": "lint-staged" 
    } 
  }, 
  "lint-staged": { 
    "*.js|{lib,setup,bin,hot,tooling,schemas}/**/*.js|test/*.js|{test,examples}/**/webpack.config.js}": [ 
      "eslint --cache" 
    ], 
    "*.{ts,json,yml,yaml,md}|examples/*.md": [ 
      "prettier --check" 
    ], 
    "*.md|{.github,benchmark,bin,examples,hot,lib,schemas,setup,tooling}/**/*.{md,yml,yaml,js,json}": [ 
      "cspell" 
    ] 
  } 
} 

不過做前端的都明白，客戶端校驗(yàn)是不可信的，通過一條命令即可繞過 git hooks。

$ git commit -n 

第三層約束：CI

git hooks可以繞過，但 CI(持續(xù)集成) 是絕對(duì)繞不過的，因?yàn)樗诜?wù)端校驗(yàn)。使用 gitlab CI 做持續(xù)集成，配置文件 .gitlab-ci.yaml 如下所示：

lint: 
  stage: lint 
  only: 
    - /^feature\/.*$/ 
  script: 
    - npm lint 

小結(jié)

• 團(tuán)隊(duì)中代碼規(guī)范統(tǒng)一是極有必要的
• 使用成熟的 eslint config，并做細(xì)節(jié)修改
• 設(shè)置部分 eslint rule 為警告，保障開發(fā)體驗(yàn)，并且在 pre-commit 與 CI 中把警告視為不通過，保證嚴(yán)格的代碼規(guī)范
• 可以在 IDE (vscode)，git hooks，CI 中添加規(guī)范校驗(yàn)攔截
• 可以使用 husky 與 lint-staged 很方便地做關(guān)于 lint 的 git hooks
• git hooks 的規(guī)范校驗(yàn)可以通過 git commit -n 跳過，需要在 CI 層繼續(xù)加強(qiáng)校驗(yàn)