<kbd id="afajh"><form id="afajh"></form></kbd>
<strong id="afajh"><dl id="afajh"></dl></strong>
    <del id="afajh"><form id="afajh"></form></del>
        1. <th id="afajh"><progress id="afajh"></progress></th>
          <b id="afajh"><abbr id="afajh"></abbr></b>
          <th id="afajh"><progress id="afajh"></progress></th>

          前端代碼規(guī)范最佳實踐

          共 3554字,需瀏覽 8分鐘

           ·

          2020-04-27 23:23

          一千個讀者,就有一千個哈姆雷特。

          一千個程序員,就有一千種代碼風(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)過的場景:

          1. 禁止掉 console.log,避免在生產(chǎn)環(huán)境輸出多余的東西。但偏偏在測試環(huán)境經(jīng)常需要調(diào)試,但是如果僅僅設(shè)為警告的話,警告又會被忽視,失去意義。
          2. 特別是當設(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

          ea8baf7dded6862b9d5e4c311df7b4ed.webp

          但是,如果你使用了 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ī)范的方式:

          1. 把 ESLint 的 rule 設(shè)置為 Warn,并在持續(xù)集成中配置環(huán)境變量 CI=true
          2. 結(jié)合 webpack 與 eslint-loader,根據(jù)當前環(huán)境的環(huán)境變量配置 emitWarning

          第一層約束: IDE

          當不符合代碼規(guī)范的第一時間,我們就要感知到它,及時反饋,快速糾正,比直到最后積攢了一大堆錯誤要高效很多。

          這里以 VS Code 作為示例,它只需要安裝一個插件:eslint,便可以做到智能提示,來看看效果吧:

          73b62ec6f724998c9519441d2cee5eeb.webp

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

          e6b86c8c3361df5b6f3d7835ef26f2c6.webp

          第二層約束: Git Hooks

          團隊合作中的編碼規(guī)范有一點是,雖然自己有可能不舒服,但是不能讓別人因為自己的代碼而不舒服。

          git 自身包含許多 hooks,在 commitpush 等 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
          ccd4499707b6237ae23c5479001dfeb6.webp

          第三層約束: CI

          git hooks 可以繞過,但 CI(持續(xù)集成) 是絕對繞不過的,因為它在服務(wù)端校驗。使用 gitlab CI 做持續(xù)集成,配置文件 .gitlab-ci.yaml 如下所示

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

          小結(jié)

          1. 團隊中代碼規(guī)范統(tǒng)一是極有必要的
          2. 使用成熟的 eslint config,并做細節(jié)修改
          3. 設(shè)置部分 eslint rule 為警告,保障開發(fā)體驗,并且在 pre-commitCI 中把警告視為不通過,保證嚴格的代碼規(guī)范
          4. 可以在 IDE (vscode)git hooksCI 中添加規(guī)范校驗攔截
          5. 可以使用 huskylint-staged 很方便地做關(guān)于 lint 的 git hooks
          6. git hooks 的規(guī)范校驗可以通過 git commit -n 跳過,需要在 CI 層繼續(xù)加強校驗

          系列文章

          1. 前端高級進階:javascript 代碼是如何被壓縮
          2. 前端高級進階:如何更好地優(yōu)化打包資源
          3. 前端高級進階:網(wǎng)站的緩存控制策略最佳實踐及注意事項
          4. 前端高級進階:在生產(chǎn)環(huán)境中使你的 npm i 速度提升 50%
          5. 前端高級進階:前端部署的發(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)在面試總是面試造火箭?

          瀏覽 36
          點贊
          評論
          收藏
          分享

          手機掃一掃分享

          分享
          舉報
          評論
          圖片
          表情
          推薦
          點贊
          評論
          收藏
          分享

          手機掃一掃分享

          分享
          舉報
          <kbd id="afajh"><form id="afajh"></form></kbd>
          <strong id="afajh"><dl id="afajh"></dl></strong>
            <del id="afajh"><form id="afajh"></form></del>
                1. <th id="afajh"><progress id="afajh"></progress></th>
                  <b id="afajh"><abbr id="afajh"></abbr></b>
                  <th id="afajh"><progress id="afajh"></progress></th>
                  亚洲综合自拍 | 痴汉无码一区二区 | 一区二区三区免费观看 | 麻妃在线中文 | 体内射精一区二区三区在线视频 |