怎么實現git代碼規(guī)范

這篇文章主要介紹“怎么實現git代碼規(guī)范”，在日常操作中，相信很多人在怎么實現git代碼規(guī)范問題上存在疑惑，小編查閱了各式資料，整理出簡單好用的操作方法，希望對大家解答”怎么實現git代碼規(guī)范”的疑惑有所幫助！接下來，請跟著小編一起來學習吧！

ESLint 與約束

統(tǒng)一編碼規(guī)范不僅可以大幅提高代碼可讀性，甚至會提高代碼質量。當我們設計了一套關于編碼規(guī)范的規(guī)則集時，需要工具去輔助檢測，這就是 ESLint。

$ npm install eslint --save-dev

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

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

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

不要重復造輪子

我們需要推到重來，設計屬于自己團隊的一套編碼規(guī)范嗎?

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

很多優(yōu)秀的團隊，都根據最佳實踐設定了特別優(yōu)秀的編碼規(guī)范，比如 airbnb 設定了一套約束特別強的規(guī)范。另外也有一些特別簡單但卻十分實用的規(guī)范，如 eslint:recommended。

airbnb javascript style[2]

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

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

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

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

是開發(fā)體驗。

一個良好的編碼規(guī)范會帶來解放強迫癥的舒適感，但過于嚴格的代碼風格有時也會使人煩躁。試舉兩個小例子，有可能是在你寫代碼時出現過的場景：

• 禁止掉 console.log，避免在生產環(huán)境輸出多余的東西。但偏偏在測試環(huán)境經常需要調試，但是如果僅僅設為警告的話，警告又會被忽視，失去意義。

• 特別是當設置了規(guī)則 no-unused-vars 時。如果僅僅是為了在開發(fā)時調試，卻因為無法通過 ESlint 規(guī)則校驗無法方便調試。

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

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

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

但是，如果你使用了 webpack，并且結合 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'),     },   ] }

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

• 把 ESLint 的 rule 設置為 Warn，并在持續(xù)集成中配置環(huán)境變量 CI=true。

• 結合 webpack 與 eslint-loader，根據當前環(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 結合可以幫助校驗 Lint，如果非通過代碼規(guī)范則不允許提交。

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

(1) husky 的原理是什么?

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

或者結合 lint-staged[4] 調用校驗規(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ù)集成) 是絕對繞不過的，因為它在服務端校驗。使用 gitlab CI 做持續(xù)集成，配置文件 .gitlab-ci.yaml 如下所示：

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

到此，關于“怎么實現git代碼規(guī)范”的學習就結束了，希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學習，快去試試吧！若想繼續(xù)學習更多相關知識，請繼續(xù)關注億速云網站，小編會繼續(xù)努力為大家?guī)砀鄬嵱玫奈恼拢?/p>