代碼規范是軟體開發領域經久不衰的話題，幾乎所有工程師在開發程序中都會遇到或思考過這一問題，而隨著前端應用的大型化和復雜化，越來越多的前端團隊也開始重視代碼規范，同樣，前段時間，筆者所在的團隊也開展了一波開源治理，而其中代碼規范就占據了很重要的一項，接下來的幾篇文章，將會對JS代碼規范、CSS規范、Git作業流規范以及檔案規范進行詳細的介紹~
系列文章：
- 前端規范之JS代碼規范（ESLint + Prettier）
- 前端規范之CSS規范（Stylelint）
- 前端規范之Gti作業流規范（Husky + Commitlint + Lint-staged）
- 前端規范之檔案規范
本文主要介紹了前端規范之JS代碼規范（ESLint + Prettier），將會對ESLint和Prettier的使用進行介紹，歡迎大家交流討論~
1. 統一代碼風格的重要性
1.1 為什么要統一代碼風格
團隊千千萬，團隊中每個人的代碼風格也是千千萬，比如有的同學寫代碼就喜歡用雙引號，縮進用兩個字符，而其他同學卻可能更喜歡用單引號，四個字符縮進，而團隊中的人一多，一往代碼倉庫提交代碼，難免會出現下面這些情況：
（1）如果沒有統一代碼風格，diff時可能會出現很多因為格式不同的問題，不便于我們查看提交代碼所做的修改
如下圖所示，提交的檔案內容其實沒有變化，只是代碼風格變了（雙引號變成了單引號，縮進從兩個字符變成了四個字符），但是diff時大段代碼會標紅，不利于我們查看提交的修改，
（2）每個團隊都有自己的標準，新人加入需要花較長時間才能熟悉團隊所使用的代碼風格，不利于效率的提
1.2 如何統一代碼風格
為了統一代碼風格，并且克服每個團隊自己制定標準所帶來的不足，一種簡單方便的方法就是采用業界提供的標準和工具，也就是我們經常所說的Lint檢查工具，前端中常用的Lint檢查工具包括了JSLint、ESLint和Stylelint等，這些工具能夠提供代碼質量和代碼風格檢查的功能，并且可以根據個人/團隊的代碼風格進行對組態檔進行配置，有效的提高了我們代碼開發的效率和質量，
下面主要列舉了我們團隊現在主要采用的一些Lint檢查工具，以及相關的VSCode輔助插件，幫助我們完成JS代碼規范、CSS代碼規范和Git作業流規范的檢查，
2. ESLint
2.1 什么是ESLint
ESLint 是一款插件化的JavaScript代碼靜態檢查工具，其核心是通過對代碼決議得到的 AST（Abstract Syntax Tree，抽象語法樹）進行模式匹配，來分析代碼達到檢查代碼質量和風格問題的能力，
ESLint 的使用其實并不復雜，安裝相關依賴之后，可以直接使用開源的配置方案，例如eslint-config-airbnb或eslint-config-standard，當然，你也可以根據個人或團隊的代碼風格進行配置，配置完成之后，就可以通過命令列工具或借助編輯器集成的 ESLint 功能對工程代碼進行靜態檢查，發現和修復不符合規范的代碼，ESLint提供的auto-fix能力也能夠幫助我們自動修復一些代碼格式問題，
2.2 安裝ESLint
（1）腳手架自動安裝
如果是采用腳手架如Vue-Cli創建專案，在創建專案時就可以選擇安裝ESLint，安裝完成后，會自動在專案根目錄生成一個.eslintrc.js檔案，里面已經生成了ESLint的初始化默認配置，
（2）手動安裝
如果是已經存在一個專案，并且想要安裝ESLint，可以通過npm的方式進行安裝，
npm install eslint --save-dev
安裝完成后，可以執行下面命令進行ESLint的初始化配置，
eslint --init
經過一系列一問一答的環節后，你會發現在你專案根目錄已經生成了一個 .eslintrc.js檔案，該檔案主要用來進行ESLint的配置，
2.3 ESLint配置方式
ESlint 被設計為完全可配置的，我們可以混合和匹配 ESLint 默認系結的規則和自己定義的規則，根據實際需求對每一個規則進行開啟或關閉，以讓 ESLint 更適合我們的專案，一般有兩種主要的方式來配置 ESLint：
（1）Configuration Comments - 使用注釋把lint規則嵌入到原始碼中
這種配置方式允許我們使用JavaScript注釋把配置資訊直接嵌入到一個代碼源檔案中，如下面的代碼所示，可以直接在代碼中使用ESLint能夠識別的注釋方式，進行Lint規則的定義，下面的規則表示如果使用console語法便會報錯，
/* eslint no-console: "error" */ console.log('this is an eslint rule check!');
當我們用命令列執行eslint xxx.js檢查上述檔案時，就會發現eslint給出報錯資訊，
（2）Configuration Files - 使用組態檔進行lint規則配置
除了上面的配置方式，另外一個更好的方式就是在專案根目錄創建組態檔進行ESLint的配置，目前組態檔主要支持以下三種檔案型別：
- JavaScript（eslintrc.js）
- YAML（eslintrc.yaml）
- JSON（eslintrc.json）
另外，我們也可以在package.json檔案中添加 eslintConfig欄位進行配置，
在我們團隊平時的開發中，一般采用了在根目錄創建.eslintrc.js的方式對eslint進行配置，如下圖所示，給出了使用Vue-Cli創建專案后.eslintrc.js中的默認配置，
module.exports = { root: true, env: { node: true, }, extends: ["plugin:vue/essential", "eslint:recommended", "@vue/prettier"], parserOptions: { parser: "babel-eslint", }, rules: { "no-console": process.env.NODE_ENV === "production" ? "warn" : "off", "no-debugger": process.env.NODE_ENV === "production" ? "warn" : "off", }, };
2.4 ESLint配置項決議
接下來主要對ESLint組態檔中的配置項進行介紹，
（1）parser決議器
ESLint 默認使用Espreer作為其決議器，但是該決議器僅支持最新的ECMPScript(es5)標準，對于實驗性的語法和非標準（例如 Flow或TypeScript型別）語法是不支持的，因此，開源社區提供了以下兩種決議器來豐富相關的功能：
babel-eslint：Babel一個工具鏈，主要用于將ECMAScript 2015+(es6+) 版本的代碼轉換為向后兼容的JavaScript語法，以便能夠運行在當前和舊版本的瀏覽器或其他環境中，因此，如果在專案中使用es6，就需要將決議器改成babel-eslint，
@typescript-eslint/parser：該決議器將TypeScript轉換成與estree兼容的形式， 允許ESLint驗證TypeScript源代碼，
（2）parserOptions決議器選項
除了可以自定義決議器外，ESLint允許指定你想要支持的JavaScript語言選項，默認情況下，ESLint支持ECMPScript 5語法，你可以覆寫該設定，以啟用對ECMPScript其它版本和JSX的支持，
（3）env和global - 環境和全域變數
ESLint 會檢測未宣告的變數，并發出警告，但是有些變數是我們引入的庫宣告的，這里就需要提前在配置中宣告，每個變數有三個選項，writable，readonly和off，分別表示可重寫，不可重寫和禁用，
{ "globals": { // 宣告 jQuery 物件為全域變數 "$": false, // true表示該變數為 writeable，而 false 表示 readonly "jQuery": false } }
在globals中一個個的進行宣告未免有點繁瑣，這個時候就需要使用到env，這是對一個環境定義的一組全域變數的預設，當然，我們可以在golbals中使用字串off禁用全域變數來覆寫env中的宣告，
{ "env": { "browser": true, "es2021": true, "jquery": true // 環境中開啟jquery，表示宣告了jquery相關的全域變數，無需在globals二次宣告 } }
如果是微信小程式開發，env并沒有定義微信小程式變數，需要在globals中手動宣告全域變數，否則在檔案中引入變數，會提示報錯，宣告如下所示：
{ globals: { wx: true, App: true, Page: true, Component: true, getApp: true, getCurrentPages: true, Behavior: true, global: true, __wxConfig: true, }, }
（4）rules規則
ESLint 附帶有大量的規則，你可以在組態檔的rules屬性中配置你想要的規則，要改變一個規則設定，你必須將規則 ID 設定為下列值之一：
- off或 0：關閉規則
- warn或 1：開啟規則，warn級別的錯誤 (不會導致程式退出)
- error或 2：開啟規則，error級別的錯誤(當被觸發的時候，程式會退出)
如以下代碼，在rules中設定關閉某些規則
rules: {'no-loop-func': 'off', 'no-param-reassign': 'off', 'no-nested-ternary': 'off', no-underscore-dangle': 'off', },
（5）plugins插件
雖然官方提供了上百種的規則可供選擇，但是這還不夠，因為官方的規則只能檢查標準的JavaScript語法，如果你寫的是JSX或者TypeScript，ESLint 的規則就開始束手無策了，
這個時候就需要安裝 ESLint 的插件，來定制一些特定的規則進行檢查，ESLint 的插件與擴展一樣有固定的命名格式，以eslint-plugin-開頭，使用的時候也可以省略這個頭，
舉個例子，我們要在專案中使用TypeScript，前面提到過，需要將決議器改為@typescript-eslint/parser，同時需要安裝@typescript-eslint/eslint-plugin插件來拓展規則，添加的plugins中的規則默認是不開啟的，我們需要在rules中選擇我們要使用的規則，也就是說 plugins是要和rules結合使用的，如下所示：
// npm i --save-dev @typescript-eslint/eslint-plugin // 注冊插件 { "parser": "@typescript-eslint/parser", "plugins": ["@typescript-eslint"], // 引入插件 "rules": { "@typescript-eslint/rule-name": "error" // 使用插件規則 '@typescript-eslint/adjacent-overload-signatures': 'error', '@typescript-eslint/ban-ts-comment': 'error', '@typescript-eslint/ban-types': 'error', '@typescript-eslint/explicit-module-boundary-types': 'warn', '@typescript-eslint/no-array-constructor': 'error', 'no-empty-function': 'off', '@typescript-eslint/no-empty-function': 'error', '@typescript-eslint/no-empty-interface': 'error', '@typescript-eslint/no-explicit-any': 'warn', '@typescript-eslint/no-extra-non-null-assertion': 'error', ... } }
（6）extends擴展
extends可以理解為一份配置好的plugin和rules，extends屬性值一般包括以下兩種：
- 指定配置的字串: 比如官方提供的兩個拓展eslint:recommended或eslint:all，可以啟用當前安裝的 ESLint 中所有的核心規則，省得我們在rules中一一配置，
- 字串陣列：每個配置繼承它前面的配置，如下所示，拓展是一個陣列，ESLint 遞回地擴展配置, 然后使用rules屬性來拓展或者覆寫extends配置規則，
{ "extends": [ "eslint:recommended", // 官方拓展 "plugin:@typescript-eslint/recommended", // 插件拓展 "standard", // npm包，開源社區流行的配置方案，比如：eslint-config-airbnb、eslint-config-standard ], "rules": { "indent": ["error", 4], // 拓展或覆寫extends配置的規則 "no-console": "off", } };
2.5 運行ESLint檢查檔案
當我們配置好.eslintrc.js檔案后，我們就可以通過運行ESLint相關命令，對指定檔案進行檢查，假設當前的專案目錄如下所示：
其中，.eslintrc.js檔案的配置如下，這里采用了Vue-Cli創建專案后給出的默認配置，
module.exports = { root: true, env: { node: true, }, extends: ["plugin:vue/essential", "eslint:recommended", "@vue/prettier"], parserOptions: { parser: "babel-eslint", }, rules: { "no-console": process.env.NODE_ENV === "production" ? "warn" : "off", "no-debugger": process.env.NODE_ENV === "production" ? "warn" : "off", }, };
當我們想對某個檔案進行檢查時，只需要在當前目錄打開命令列視窗，輸入以下命令，就可以對某個檔案或某個目錄下的所有檔案進行檢查，如果執行完命令后什么也沒有輸出，就說明我們的代碼已經通過ESLint檢查，可以放心提交代碼，
eslint src/APP.vue // 檢查指定的檔案
eslint src/*.vue // 檢查src目錄下的所有檔案
但是如果出現以下提示或報錯，就說明我們的代碼沒有通過ESLint的檢查，需要按照提示進行修改，
有些同學一執行完上述命令，可能會嚇了一跳，怎么報了這么多錯誤？不急，我們可以執行以下的ESLint自動修復命令，對一些錯誤進行自動修復，不過，這個命令只能自動修復一些代碼格式上的錯誤（比如ESLint的配置要求需要使用雙引號，但是寫代碼時采用了單引號而報錯），對于一些語法錯誤，就需要我們手動去修復，
eslint src/APP.vue --fix // 檢查指定的檔案，并且自動修復錯誤 eslint src/*.vue --fix // 檢查src目錄下的所有檔案，并且自動修復錯誤
2.6 跳過ESLint的檢查
在實際的使用場景中，我們可能存在某些檔案或某行代碼，希望能夠跳過ESLint的檢查，下面主要介紹了幾種跳過ESLint檢查的方式：
（1）使用注釋跳過ESLint的檢查
- 塊注釋： 使用如下方式，可以在整個檔案或者代碼塊禁用所有規則或者禁用特定規則：
/* eslint-disable */ alert('該注釋放在檔案頂部，整個檔案都不會出現 lint 警告'); /* eslint-disable */ alert('塊注釋 - 禁用所有規則'); /* eslint-enable */ /* eslint-disable no-console, no-alert */ alert('塊注釋 - 禁用 no-console, no-alert 特定規則'); /* eslint-enable no-console, no-alert */
- 行注釋： 使用如下方式可以在某一特定的行上禁用所有規則或者禁用特定規則：
alert('禁用該行所有規則'); // eslint-disable-line
// eslint-disable-next-line
alert('禁用該行所有規則');
/* eslint-disable-next-line no-alert */
alert('禁用該行 no-alert 特定規則');
alert(
'禁用該行 no-alert, quotes, semi 特定規則'
); /* eslint-disable-line no-alert, quotes, semi*/
（2）創建.eslintignore檔案忽略某些檔案的檢查
在專案根目錄創建.eslintignore檔案，在該檔案中添加需要跳過檢查的檔案名稱，ESLint將會跳過這些檔案的檢查，如下所示，ESLint將會跳過dist、node_modules和package.json檔案的檢查，
dist
node_modules
package.json
3. Prettier
3.1 什么是Prettier
Prettier是一個代碼格式化工具，可以格式化代碼，但不具備代碼檢查功能，它可以通過決議代碼并使用自己的規則重新列印它，并考慮最大行長來強制一致的樣式，并在必要時包裝代碼，如今，它已成為解決所有代碼格式問題的優選方案，支持多種語言，可以將ESLint和Prettier結合使用，提高代碼質量，
3.2 為什么要用Prettier
上面Prettier的定義一看，是不是覺得和ESLint差不了多少？那么，有了ESLint，為什么還要用Prettier呢？
其實呀，ESLint雖然是一個代碼檢測工具，可以檢測代碼質量問題并給出提示，但是提供的格式化功能有限，在代碼風格上面做的不是很好，并且也只能格式化JS，不支持CSS,HTML等語言，而在代碼風格上面，Prettier具有更加強大的功能，并且能夠支持包括 JavaScript、TypeScript、各種 CSS、Vue 和 Markdown 等前端絕大部分的語言和檔案格式，因此，我們一般會將ESLint和Prettier一起結合起來使用，用ESLint進行代碼校驗，用Prettier統一代碼風格，
3.3 安裝Prettier
（1）腳手架自動安裝
如果是采用腳手架如Vue-Cli創建專案，在創建專案時就可以選擇安裝Prettier，安裝完成后，會自動在專案根目錄生成一個.eslintrc.js檔案，里面的默認配置中已經包含了prettier的相關擴展，
（2）手動安裝
如果已經存在一個專案，并且想要安裝Prettier，可以通過npm的方式進行安裝，
npm install prettier --save-dev
3.4 安裝eslint-config-prettier
安裝好Prettier之后，我們還需要安裝eslint-config-prettier，這是因為eslint和prettier里面的一些規則可能會存在沖突，這個時候我們就需要安裝eslint-config-prettier，并且關掉所有和prettier沖突的eslint配置，
通過npm安裝eslint-config-prettier，
npm install eslint-config-prettier --save-dev
安裝好eslint-config-prettier之后，接下來我們就需要關掉所有和prettier沖突的eslint配置，這里只需要在.eslintrc.js的extends中將prettier設定為最后一個extends即可，相當于用 prettier 的規則，覆寫掉 eslint:recommended 的部分規則，
extends: ["eslint:recommended", "prettier"],
3.5 安裝eslint-plugin-prettier
接下來，我們還需要安裝eslint-plugin-prettier，eslint-plugin-prettier的作用時是將prettier 的能力集成到eslint中，使得我們在運行eslint檢查我們的代碼時，能夠按照prettier的規則檢查代碼規范性，并進行修復，
使用npm安裝eslint-plugin-prettier，
npm install eslint-plugin-prettier
安裝eslint-plugin-prettier后，需要對.eslintrc.js進行配置，
{ "rules":{ "prettier/prettier":"error" }, "plugins": ["prettier"]，
}
除了上面這種配置之外，我們也可以直接將上面兩個步驟結合在一起，使用下面的配置就可以，
{ "extends": [ "eslint:recommended", "plugin:prettier/recommended" ] }
3.6 組態檔
Prettier和ESLint一樣，支持我們通過組態檔的方式，實作自定義配置，覆寫原來的Prettier配置，
我們可以在根目錄創建.prettierrc檔案，.prettierrc檔案支持寫入YAML，JSON的配置格式，并且支持.yaml，.yml，.json和.js后綴，在平時的開發中，我們團隊一般會選擇創建.prettierrc.js檔案，實作對prettier配置的覆寫，
在.prettierrc.js檔案中，我們可以對prettier的默認配置進行修改，
module.exports = { // 一行最多 120 字符 printWidth: 120, // 使用 2 個空格縮進 tabWidth: 2, // 不使用縮進符，而使用空格 useTabs: false, // 行尾需要有分號 semi: true, // 使用單引號 singleQuote: true, // 物件的 key 僅在必要時用引號 quoteProps: 'as-needed', // jsx 不使用單引號，而使用雙引號 jsxSingleQuote: false, // 末尾需要有逗號 trailingComma: 'all', // 大括號內的首尾需要空格 bracketSpacing: true, // jsx 標簽的反尖括號需要換行 jsxBracketSameLine: false, // 箭頭函式，只有一個引數的時候，也需要括號 arrowParens: 'always', // 每個檔案格式化的范圍是檔案的全部內容 rangeStart: 0, rangeEnd: null, // 不需要寫檔案開頭的 @prettier requirePragma: false, // 不需要自動在檔案開頭插入 @prettier insertPragma: false, // 使用默認的折行標準 proseWrap: 'preserve', // 根據顯示樣式決定 html 要不要折行 htmlWhitespaceSensitivity: 'css', // vue 檔案中的 script 和 style 內不用縮進 vueIndentScriptAndStyle: false, // 換行符使用 lf endOfLine: 'lf', // 格式化內嵌代碼 embeddedLanguageFormatting: 'auto', };
3.7 忽略某些檔案的格式化
Prettier和ESLint一樣，也支持忽略對某些檔案的格式化，如果我們存在一些不需要格式化的檔案，可以在根目錄創建.prettierignore檔案，并且將不需要格式化的檔案或目錄名稱寫在該檔案中，
dist
node_modules
.eslintignore
.prettierignore
4. VSCode插件
4.1 安裝VSCode插件
配置好ESLint和Prettier之后，我們通過運行eslint命令，就可以對我們代碼進行檢查啦，但是，每次要手動運行命令才能檢查我們的代碼還是有點麻煩，有沒有更簡單的方式，讓我們在撰寫代碼的程序中，就能夠對我們的代碼進行檢查，并且自動修復一些錯誤呢？接下來，接下來，VSCode插件就登場啦~
首先，我們需要安裝的ESLint插件，安裝方法很簡單，在VSCode的EXTENSIONS中找到ESLint插件，然后點擊install就可以啦，
接著，我們還需要安裝Prettier插件，
最后，我們也把EditorConfig for VS Code插件安裝上，這個插件可以讓編譯器讀取組態檔，并且按照組態檔里面的規定來格式化代碼，有了這個插件，只要定義好一份組態檔，就算團隊成員用的編譯器不同，也能夠輸出風格統一的代碼，
4.2 配置setting.json檔案
安裝好插件之后，我們還需要設定VSCode的setting.json檔案，實作保存代碼時就自動執行ESLint檢查，VSCode的setting.json設定分為作業區和用戶兩個級別，其中用戶區會對所有專案生效，而作業區的設定只會對當前專案生效，
（1）用戶區setting.json配置
點擊VSCode左下角的設定按鈕，選擇Settings，選擇以文本編輯形式打開setting.json，并且在setting.json中加入以下代碼，配置完成之后，當我們保存某個檔案時，就可以自動對當前檔案進行ESLint檢查，并且自動對一些錯誤進行修復啦，
{ // #每次保存的時候自動格式化 "editor.formatOnSave": true, "editor.codeActionsOnSave": { "source.fixAll.eslint": true },
（2）作業區setting.json配置
除了配置用戶區的setting.json之外，我們也可以配置作業區的setting.json，作業區的配置只會對當前專案生效，
首先，我們需要在專案根目錄創建.vscode目錄，并且在該目錄下創建setting.json檔案，
接著，在setting.json中加入以下代碼，配置完成后，當我們保存該專案中某個檔案時，也會自動對該檔案進行ESLint檢查，并且自動修復一些問題，
{ "editor.formatOnSave": true, "editor.codeActionsOnSave": { "source.fixAll.eslint": true, }, "eslint.validate": ["typescript", "javascript", "vue"] }
4.3 配置EditorConfig檔案
上面在安裝VSCode插件時，我們提到了要安裝EditorConfig for VS Code插件，那這個插件需要怎么起作用呢？
首先，我們需要在專案根目錄創建.editorconfig檔案，創建完成之后，這個檔案里面定義的代碼規范規則會高于編譯器默認的代碼規范規則，
接著，我們只需要在.editorconfig檔案中加入我們想要覆寫的編譯器的配置，比如下面的配置定義了縮進為2個空格，那么就算編譯器默認的是4個空格的縮進，最后也會按照我們的.editorconfig配置，按照2個空格進行縮進，
root = true [*] charset = utf-8 indent_style = space indent_size = 2 insert_final_newline = true trim_trailing_whitespace = true end_of_line = auto
當我們完成上面的步驟之后，接下來我們只要撰寫代碼，保存，就能夠得到一份風格統一的代碼啦~
轉載請註明出處，本文鏈接：https://www.uj5u.com/qiye/303496.html
標籤：其他