代碼規范優秀實踐
一千個讀者，就有一千個哈姆雷特。
一千個程序員，就有一千種代碼風格。
那什么是代碼風格呢?從小的來說，有的開發喜歡帶分號，有的不喜歡帶分號。有的喜歡使用空格，有的喜歡使用 Tab。有的喜歡空兩個空格，有的喜歡四個空格。除了這些，還有一些關于代碼的優化，如避免聲明未使用，避免冗余的代碼邏輯等。如果你是新參加工作的人員，又恰好遇到一個代碼風格混亂，密密麻麻賦值前后都不帶空格的項目，只能有苦難言了。
因此團隊合作中需要統一規范。
ESLint 與約束
統一編碼規范不僅可以大幅提高代碼可讀性，甚至會提高代碼質量。當我們設計了一套關于編碼規范的規則集時，需要工具去輔助檢測，這就是 ESLint。
- $ npm install eslint --save-dev
規則集需要統一集中配置，ESLint 會默認讀取配置文件 .eslintrc 來解析，而規則集在 rules 中進行配置：
- {
- "rules": {
- "semi": ["error", "always"],
- "quotes": ["error", "double"]
- }
- }
而我們需要做的是設定我們的代碼規范，即 rules 項。
不要重復造輪子
我們需要推到重來，設計屬于自己團隊的一套編碼規范嗎?
完全沒有必要推倒重來，既耗費人力，又難以做到規則的全部覆蓋。
很多優秀的團隊，都根據最佳實踐設定了特別優秀的編碼規范，比如 airbnb 設定了一套約束特別強的規范。另外也有一些特別簡單但卻十分實用的規范，如 eslint:recommended。
airbnb javascript style[2]
我們僅僅需要使用 extend 配置項去繼承一些優秀的開源的代碼規范，并使用 rules 做一些自己團隊的規則補充。
- {
- "extend": ["airbnb-base"],
- "rules": {
- "semi": ["error", "never"]
- }
- }
開發環境，生產環境與警告
開發環境對于開發而言重要的是什么?
是開發體驗。
一個良好的編碼規范會帶來解放強迫癥的舒適感，但過于嚴格的代碼風格有時也會使人煩躁。試舉兩個小例子，有可能是在你寫代碼時出現過的場景：
- 禁止掉 console.log，避免在生產環境輸出多余的東西。但偏偏在測試環境經常需要調試，但是如果僅僅設為警告的話，警告又會被忽視，失去意義。
- 特別是當設置了規則 no-unused-vars 時。如果僅僅是為了在開發時調試，卻因為無法通過 ESlint 規則校驗無法方便調試。
這是一個約束與自由的權衡，ESLint 在提供強有力約束時自然會犧牲一些開發上的便利性。中庸，儒家思想講究中庸，此時可以在權衡下選擇一個中庸的方案：
把 ESLint 的所有影響調試的規則校驗都設置為 Warn，那你又問了警告往往不是會被忽略嗎?是這樣子的，所以需要在 CI 中設置環境變量 CI=true，如此在 CI 中即使有警告也無法交付。
如在 create-react-app 中的大部分規則都是設置為 Warn
但是，如果你使用了 webpack，并且結合 eslint-loader，那解決方案就更加簡單了：使用 emitWarning: true，在測試環境把所有 Error 都當做 Warn，這樣避免了修改 ESLint 規則，webpack 的配置如下：
- {
- test: /\.(js|mjs|jsx|ts|tsx)$/,
- enforce: 'pre',
- use: [
- {
- options: {
- cache: true,
- emitWarning: true,
- },
- loader: require.resolve('eslint-loader'),
- },
- ]
- }
所以有兩種權衡開發體驗與編程規范的方式：
- 把 ESLint 的 rule 設置為 Warn，并在持續集成中配置環境變量 CI=true。
- 結合 webpack 與 eslint-loader，根據當前環境的環境變量配置 emitWarning。
第一層約束：IDE
當不符合代碼規范的第一時間，我們就要感知到它，及時反饋，快速糾正，比直到最后積攢了一大堆錯誤要高效很多。
這里以 VS Code 作為示例，它只需要安裝一個插件：eslint，便可以做到智能提示，來看看效果吧：
另外，配合 eslint-loader，使用瀏覽器也可以做到實時提示：
第二層約束：Git Hooks
團隊合作中的編碼規范有一點是，雖然自己有可能不舒服，但是不能讓別人因為自己的代碼而不舒服。
git 自身包含許多 hooks，在 commit，push 等 git 事件前后觸發執行。與 pre-commit hook 結合可以幫助校驗 Lint，如果非通過代碼規范則不允許提交。
husky[3] 是一個使 git hooks 變得更簡單的工具，只需要配置幾行 package.json 就可以愉快的開始工作。
(1) husky 的原理是什么?
- // package.json
- {
- "scripts": {
- "lint": "eslint . --cache"
- },
- "husky": {
- "hooks": {
- "pre-commit": "npm lint",
- }
- }
- }
或者結合 lint-staged[4] 調用校驗規則
- {
- "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"
- ]
- }
- }
不過做前端的都明白，客戶端校驗是不可信的，通過一條命令即可繞過 git hooks。
- $ git commit -n
第三層約束：CI
git hooks可以繞過，但 CI(持續集成) 是絕對繞不過的，因為它在服務端校驗。使用 gitlab CI 做持續集成，配置文件 .gitlab-ci.yaml 如下所示：
- lint:
- stage: lint
- only:
- - /^feature\/.*$/
- script:
- - npm lint
小結
- 團隊中代碼規范統一是極有必要的
- 使用成熟的 eslint config，并做細節修改
- 設置部分 eslint rule 為警告，保障開發體驗，并且在 pre-commit 與 CI 中把警告視為不通過，保證嚴格的代碼規范
- 可以在 IDE (vscode)，git hooks，CI 中添加規范校驗攔截
- 可以使用 husky 與 lint-staged 很方便地做關于 lint 的 git hooks
- git hooks 的規范校驗可以通過 git commit -n 跳過，需要在 CI 層繼續加強校驗
