前端代碼規(guī)范最佳實踐
一千個讀者,就有一千個哈姆雷特。
一千個程序員,就有一千種代碼風(fēng)格。
那什么是代碼風(fēng)格呢?從小的來說,有的開發(fā)喜歡帶分號,有的不喜歡帶分號。有的喜歡使用空格,有的喜歡使用 Tab。有的喜歡空兩個空格,有的喜歡四個空格。除了這些,還有一些關(guān)于代碼的優(yōu)化,如避免聲明未使用,避免冗余的代碼邏輯等。如果你是新參加工作的人員,又恰好遇到一個代碼風(fēng)格混亂,密密麻麻賦值前后都不帶空格的項目,只能有苦難言了。
因此團隊合作中需要統(tǒng)一規(guī)范。
ESLint 與約束
統(tǒng)一編碼規(guī)范不僅可以大幅提高代碼可讀性,甚至?xí)岣叽a質(zhì)量。當我們設(shè)計了一套關(guān)于編碼規(guī)范的規(guī)則集時,需要工具去輔助檢測,這就是 ESLint。
$ npm install eslint --save-dev
規(guī)則集需要統(tǒng)一集中配置,ESLint 會默認讀取配置文件 .eslintrc 來解析,而規(guī)則集在 rules 中進行配置:
{
"rules": {
"semi": ["error", "always"],
"quotes": ["error", "double"]
}
}
而我們需要做的是設(shè)定我們的代碼規(guī)范,即 rules 項,關(guān)于它的文檔及最佳實踐參考下文:
- ESLint Rules and Best Practices[1]
不要重復(fù)造輪子
我們需要推到重來,設(shè)計屬于自己團隊的一套編碼規(guī)范嗎?
完全沒有必要推倒重來,既耗費人力,又難以做到規(guī)則的全部覆蓋。
很多優(yōu)秀的團隊,都根據(jù)最佳實踐設(shè)定了特別優(yōu)秀的編碼規(guī)范,比如 airbnb 設(shè)定了一套約束特別強的規(guī)范。另外也有一些特別簡單但卻十分實用的規(guī)范,如 eslint:recommended。
- airbnb javascript style[2]
我們僅僅需要使用 extend 配置項去繼承一些優(yōu)秀的開源的代碼規(guī)范,并使用 rules 做一些自己團隊的規(guī)則補充。
{
"extend": ["airbnb-base"],
"rules": {
"semi": ["error", "never"]
}
}
開發(fā)環(huán)境,生產(chǎn)環(huán)境與警告
開發(fā)環(huán)境對于開發(fā)而言重要的是什么?
是開發(fā)體驗。
一個良好的編碼規(guī)范會帶來解放強迫癥的舒適感,但過于嚴格的代碼風(fēng)格有時也會使人煩躁。試舉兩個小例子,有可能是在你寫代碼時出現(xiàn)過的場景:
- 禁止掉
console.log,避免在生產(chǎn)環(huán)境輸出多余的東西。但偏偏在測試環(huán)境經(jīng)常需要調(diào)試,但是如果僅僅設(shè)為警告的話,警告又會被忽視,失去意義。 - 特別是當設(shè)置了規(guī)則
no-unused-vars時。如果僅僅是為了在開發(fā)時調(diào)試,卻因為無法通過 ESlint 規(guī)則校驗無法方便調(diào)試。
這是一個約束與自由的權(quán)衡,ESLint 在提供強有力約束時自然會犧牲一些開發(fā)上的便利性。中庸,儒家思想講究中庸,此時可以在權(quán)衡下選擇一個中庸的方案:
把 ESLint 的所有影響調(diào)試的規(guī)則校驗都設(shè)置為 Warn,那你又問了警告往往不是會被忽略嗎?是這樣子的,所以需要在 CI 中設(shè)置環(huán)境變量 CI=true,如此在 CI 中即使有警告也無法交付。CI 指持續(xù)集成,在本篇文章后邊也會接著提到,另外,在本系列文章中也會重點講解 CI,歡迎持續(xù)關(guān)注。
如在 create-react-app 中的大部分規(guī)則都是設(shè)置為 Warn

但是,如果你使用了 webpack,并且結(jié)合 eslint-loader,那解決方案就更加簡單了:使用 emitWarning: true,在測試環(huán)境把所有 Error 都當做 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ā)體驗與編程規(guī)范的方式:
- 把 ESLint 的 rule 設(shè)置為
Warn,并在持續(xù)集成中配置環(huán)境變量CI=true。 - 結(jié)合 webpack 與
eslint-loader,根據(jù)當前環(huán)境的環(huán)境變量配置emitWarning。
第一層約束: IDE
當不符合代碼規(guī)范的第一時間,我們就要感知到它,及時反饋,快速糾正,比直到最后積攢了一大堆錯誤要高效很多。
這里以 VS Code 作為示例,它只需要安裝一個插件:eslint,便可以做到智能提示,來看看效果吧:

另外,配合 eslint-loader,使用瀏覽器也可以做到實時提示:

第二層約束: Git Hooks
團隊合作中的編碼規(guī)范有一點是,雖然自己有可能不舒服,但是不能讓別人因為自己的代碼而不舒服。
git 自身包含許多 hooks,在 commit,push 等 git 事件前后觸發(fā)執(zhí)行。與 pre-commit hook 結(jié)合可以幫助校驗 Lint,如果非通過代碼規(guī)范則不允許提交。
husky[3] 是一個使 git hooks 變得更簡單的工具,只需要配置幾行 package.json 就可以愉快的開始工作。
husky 的原理是什么?
// package.json
{
"scripts": {
"lint": "eslint . --cache"
},
"husky": {
"hooks": {
"pre-commit": "npm lint",
}
}
}
或者結(jié)合 lint-staged[4] 調(diào)用校驗規(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"
]
}
}
不過做前端的都明白,客戶端校驗是不可信的,通過一條命令即可繞過 git hooks。
$ git commit -n

第三層約束: CI
git hooks 可以繞過,但 CI(持續(xù)集成) 是絕對繞不過的,因為它在服務(wù)端校驗。使用 gitlab CI 做持續(xù)集成,配置文件 .gitlab-ci.yaml 如下所示
lint:
stage: lint
only:
- /^feature\/.*$/
script:
- npm lint
小結(jié)
- 團隊中代碼規(guī)范統(tǒng)一是極有必要的
- 使用成熟的 eslint config,并做細節(jié)修改
- 設(shè)置部分 eslint rule 為警告,保障開發(fā)體驗,并且在
pre-commit與CI中把警告視為不通過,保證嚴格的代碼規(guī)范 - 可以在
IDE (vscode),git hooks,CI中添加規(guī)范校驗攔截 - 可以使用
husky與lint-staged很方便地做關(guān)于 lint 的git hooks git hooks的規(guī)范校驗可以通過git commit -n跳過,需要在 CI 層繼續(xù)加強校驗
系列文章
- 前端高級進階:javascript 代碼是如何被壓縮
- 前端高級進階:如何更好地優(yōu)化打包資源
- 前端高級進階:網(wǎng)站的緩存控制策略最佳實踐及注意事項
- 前端高級進階:在生產(chǎn)環(huán)境中使你的 npm i 速度提升 50%
- 前端高級進階:前端部署的發(fā)展歷程
參考資料
[1]ESLint Rules and Best Practices: https://eslint.org/docs/rules/
[2]airbnb javascript style: https://github.com/airbnb/javascript
[3]husky: https://github.com/typicode/husky
[4]lint-staged: https://github.com/okonet/lint-staged
推薦閱讀
我的公眾號能帶來什么價值?(文末有送書規(guī)則,一定要看)
每個前端工程師都應(yīng)該了解的圖片知識(長文建議收藏)
為什么現(xiàn)在面試總是面試造火箭?
