代碼規范

每個團隊、每個人都有自己的代碼規范。

規范的代碼可以讓整個項目的編碼風格更統一。

一個項目的代碼規范涉及許多方面：

• 是否該用分號結尾
• 可否使用位運算符
• 能不能寫行 if 語句
• 是否必須要用函數聲明的形式創建函數
• …

在沒有工具檢測的情況下，統一多人項目的編碼風格是一件比較困難的事情，每次提交代碼都需要詳細的 review 每一行代碼，因為這些規范點都非常細。

好在目前的前端生態有許多工具幫我們解決這個問題。

代碼是否符合規范，就是要對代碼進行檢查。
對 JavaScript 代碼的檢查，目前使用最多最廣的是 ESLint。

1. ESLint

可組裝的JavaScript和JSX檢查工具

ESLint 的主要作用就是檢查代碼，許多不符合規范的代碼還可以通過 ESLint 直接修復。

1.1 安裝 ESLint

ESLint 可以直接使用 npm 安裝。

首先在空目錄創建一個項目，然后安裝 ESLint。

npm init -y

npm i eslint -D

安裝后修改 package.json 的 scripts 配置項。

{
  "scripts": {
    "lint": "eslint ./src/**/*.*"
  }
}

eslint 命令就可以執行 eslint，./src/**/*.* 表示檢查 src 目錄開始的所有文件。

接下來創建配置文件：

1.2 創建配置文件

在項目根目錄下創建一個 .eslintrc.js 的配置文件，.eslintrc 是 eslint 會去默認找的配置文件名。

eslint 可以用多種格式的配置，如 JSON、YAML，通常會選則 .js 文件，因為可以方便書寫一些環境相關的邏輯、寫注釋等。

// .eslintrc.js
module.exports = {
  'rules': { // 椒鹽規則
    'indent': [ // 鎖進為2個一鎖 不然報錯
      'error',
      2,
    ],
    'quotes': [ // 引號必須使用單引號 不然報錯
      'error',
      'single',
    ],
    'semi': [ // 語句結束必須要分號 不然報錯
      'error',
      'always',
    ],
  },
};

配置文件創建后可以在項目下創建 src 目錄，并且寫一個不符合規則的 .js 文件。

// ./src/index.js
var number = 1

if (number < 10) {
    console.log("咕咕？");
}

完成后，就可以執行 npm run lint 命令了。

可以看到其炸了三個 error 級別的通知，因為在配置的時候提供的級別就是 error。

第一個 Missing semicolon，就是表示沒有分號。
第二個 Expected indentation of 2 spaces but found 4，表示應該需要2個鎖進，但其實有4個。
第三個 Strings must use singlequote，表示字符串應使用單引號包裹。

eslint 通過提供的配置規則來檢查代碼，發現不符合規則的部分就會告訴你錯誤。

如果把他提供的錯誤都修好，代碼檢測就會正常通過。

// ./src/index.js
var number = 1;

if (number < 10) {
  console.log('咕咕？');
}

如果放心把修復的權利交給 eslint，可以使用 eslint ./src/**/*.* --fix 命令，來修復這些報錯。

// package.json
{
  "scripts": {
    "fix": "eslint ./src/**/*.* --fix"
  }
}

增加 fix 命令后執行 npm run fix，就會根據配置修復報錯。

eslint --init 命令會調用 eslint 并以交互問答方式來快速創建一個配置文件。

2. 小結

ESLint 的規則有許多，還有很多大廠使用的預設規范，ESLint 也采用了配置項的方式可以配置。

對團隊規范的檢查其實就是將團隊內的規則映射到 ESLint 的規則上。

許多編輯器和 IDE 都有對 eslint 規則的分析，從而對代碼進行靜態檢查，在推送代碼前就可以處理掉很多問題，通常情況下代碼的規范檢查發生在 git commit 的時候，git 提供了對應階段的鉤子。

如果需要對樣式進行檢查，可以考慮使用 stylelint， 使用方式和 eslint 大同小異。