前端工程化之——代碼規範五部曲

一、EditorConfig

EditorConfig是幫助跨各種編輯器和ide處理同一項目的多個開發人員維護一致的編碼風格,文件中的設置會優先於用戶/工作區設置,在開發過程中,可以通過對編輯器配置編碼規則在開發過程就對代碼的風格進行初步的統一。
有些編譯器自帶對.editorConfig這個文件的支持(可以識別這個文件中所配置的規則),有些則需要自行安裝插件,VS Code需要安裝插件EditorConfig for VS CODE
配置方法:在項目的根目錄下創建.editorConfig文件,配置如下:

# .editorConfig文件配置:

# 當打開一個文件時,EditorConfig插件會在打開的文件目錄和每個父目錄中查找一個名爲.editorConfig的文件。
# 如果找到了根文件路徑或者找到了帶有root=true的EditorConfig文件,那麼對.editorConfig文件的搜索就會停止。
root = true 

# 匹配的文件
[*] 

# 縮進的類型 [space | tab] 
indent_style = space 

# indent_size應該設置爲tab的大小,製表符的大小應該是tab_width(如果指定的話);否則爲編輯器設置的選項卡大小。這些值不區分大小寫。
# tab_width: 設置爲一個整數,定義用於表示tab的列數。默認爲indent_size的值,通常不需要指定。
indent_size = 2 

# 定義換行符 [lf | cr | crlf] ,這些值不區分大小寫
end_of_line = lf 

# 編碼格式。支持latin1、utf-8、utf-8-bom、utf-16be和utf-16le,不建議使用uft-8-bom。 
charset = utf-8 

# 將其設置爲true以刪除文件中換行符之前的所有空格字符,將其設置爲false以確保不刪除換行符。
trim_trailing_whitespace = true 

# 文件是否以一個空白行結尾 [true | false] 
insert_final_newline = true

可以查閱官方根據需要再進行個性化配置EditConfig

二、ESLint

.eslintrc

ESLint是在ECMAScript/JavaScript代碼中按照語法規則識別並且並給出報告的代碼檢測工具,它的作用是保證代碼語法的一致性和避免錯誤。主要針對語法方面(比如無效變量,變量未申明使用等語法)的是無效的,這方面可以交給ESLint。
使用ESLint,必須要安裝它,可以本地安裝或全局安裝:

// 本地安裝
npm install eslint --save-dev
// 全局安裝
npm install eslint --global

可以進入 ./node_modules/.bin/eslint 目錄執行 --init 創建,或者自己創建一個 .eslintrc 文件,或者直接在 package.json 文件中通過 eslintConfig 字段指定配置,ESLint 會查找和自動讀取它們。

./node_modules/.bin/eslint --init

.eslintrc.js配置文件可參考如下配置如下:

module.exports = {
    // extend 屬性可以說指定配置的字符串
    // 這裏'plugin:vue/essential'是eslint-plugin-vue插件關於vue的配置(要install eslint-plugin-vue)
    // '@vue/prettier' 是@vue/eslint-config-prettier插件關於vue的美化工具(要install @vue/eslint-config-prettier)
    "extends": ['plugin:vue/essential', '@vue/prettier'],

    // 使用prettier進行處理,對prettier處理後的代碼eslint再進行語法檢測
    "plugins": [
        "prettier"
    ],
    // 可根據需要配置額外規則,
    //"off" 或者 0:關閉規則。
    //"warn" 或者 1:打開規則,並且作爲一個警告(不影響exit code)。
    //"error" 或者 2:打開規則,並且作爲一個錯誤(exit code將會是1)。
    "rules": {
        "quotes": ["error", "double"], //強制使用一致的單引號
        "semi": ["error", "always"], //強制行尾部分號

        // 可以覆蓋基本配置規則的默認選項
        "comma-dangle": ["error", "always"], //數組和對象鍵值對最後一個必須帶逗號
        "no-use-before-define": 2 //不允許在變量定義之前使用它們。

        // 禁用基本配置中的規則
        "no-console": "off", //關閉禁用 console
    }
}

.eslintignore

配置需要忽略檢查的文件和目錄,避免對不必要的文件也進行校驗增加檢測時長,參考配置如下:

# .eslintignore文件
/dist/
/node_modules/
/static/
/public/

三、Prettier

.prettierrc

Perttier可以美化代碼,主要是書寫規則方面的。
使用prettier需要先安裝,可以局部安裝或全局安裝:

# 局部安裝
npm install --save-dev --save-exact prettier
# 全局
npm install --global prettier

perttier的執行可以配置到 .eslintrc.js文件的plugin中,當成eslint的插件來使用,.prettierrc.js配置如下:

module.exports = {
  //每行最多多少個字符換行默認80
  printWidth: 150,
  //tab縮進大小,默認爲2
  tabWidth: 2,
  //使用分號, 默認true
  semi: true,
  //使用單引號, 默認false(在jsx中配置無效, 默認都是雙引號)
  singleQuote: true,
  //行尾逗號,默認none,可選 none|es5|all
  trailingComma: 'none',
  // 對象中的空格 默認true
  // true: { foo: bar }
  // false: {foo: bar}
  bracketSpacing: true,
  // JSX標籤閉合位置 默認false
  // false: <div
  //          className=""
  //          style={{}}
  //       >
  // true: <div
  //          className=""
  //          style={{}} >
  jsxBracketSameLine: true,
  // 箭頭函數參數括號 默認avoid 可選 avoid| always
  // avoid 能省略括號的時候就省略 例如x => x
  // always 總是有括號
  arrowParens: 'avoid',
  //行結尾的風格<auto | lf | crlf | cr>
  endOfLine: 'auto'
};

.prettierignore.js

使用 prettierignore 來對不需要進行檢查的文件夾進行忽略,配置如下:

/dist/
/node_modules/
/static/
/public/

四、StyleLint

.stylelintrc.js

對於樣式部分的檢查可以使用styleLint,它可以識別scss語法
需要安裝stylelint包

npm install -g stylelint --save-dev

在項目中添加配置文件".stylelintrc.js"

module.exports = {
  extends: ['stylelint-config-prettier', 'stylelint-config-standard', './node_modules/prettier-stylelint/config.js'],
  rules: {
    // 定義一些適合團隊約定的規則
    'no-empty-source': null,
    'color-hex-case': null,
    'rule-empty-line-before': null
  }
};

.stylelintignore.js

使用 stylelintignore 來對不需要進行檢查的文件夾進行忽略,配置如下:

/dist/
/node_modules/
/static/
/public/

五、hushy+Lint-staged+Commitlint

上面幾部是在開發的過程進行格式化,這最後一步是在代碼最終提交到遠程的時候進行的最後一次把關,保證提交的代碼是符合規範的。
其中,husky提供git的鉤子功能,可以在git的各個階段執行相關操作,利用hushy在預提交代碼的時候進行Lint檢查 ,需要npm安裝husky

 npm install husky --save-dev

lint-staged 工具是用來識別被加入到stage區文件,使用它來避免對項目中進行全項目掃描所會增加了檢查複雜度和時長,我們只需要檢查我們要提交的代碼就可以了。需要安裝lint-staged;

npm install lint-staged --save-dev

Commitlint用於檢查我們的commit message是否符合提交規範,如果不符合,則直接拒絕提交 。

npm install -g @commitlint/cli @commitlint/config-conventional

@commitlint/cli 是git commit lint工具
@commitlint/config-conventional 可共享的commitlint配置執行常規提交配置,校驗時不滿足規則則會退出

這裏的配置需要三步:

第一步:這裏把提交檢測配置在在package.json中,配置如下:

// Git鉤子對應的操作
"husky": {
  "hooks": {
    "pre-commit": "lint-staged" // 在代碼commit前執行將加入到stage暫存區的文件進行檢查,按照"lint-staged"中的規則進行檢查
    "commit-msg": "commitlint -E HUSKY_GIT_PARAMS" 
  }
},
// 對staged的文件進行lint,避免對整個項目進行lint代碼龐大且緩慢
"lint-staged": {
    "linters": {
      "src/**/*.js": [  // 匹配.js文件一下命令
        "eslint --fix", // 執行eslint進行掃描進行fix
        "prettier --write", //執行prettier腳本,對代碼鏡像格式化
        "git add" //上述兩項任務完成後對代碼重新add。
      ],
      "src/**/*.vue": [
        "eslint --fix",
        "stylelint --fix",
        "prettier --write",
        "git add"
      ],
      "src/**/*.scss": [
        "stylelint --syntax=scss --fix",
        "prettier --write",
        "git add"
      ],
      "ignore": [
        "/dist/",
        "/node_modules/",
        "/static/",
        "/public/"
      ]
    }
  },

第二步:在項目目錄下創建 commitlint.config.js 文件,加入:

/**
build:主要目的是修改項目構建系統(例如 glup,webpack,rollup 的配置等)的提交
ci:主要目的是修改項目繼續集成流程(例如 Travis,Jenkins,GitLab CI,Circle等)的提交
docs:文檔更新
feat:新增功能
fix:bug 修復
perf:性能優化
refactor:重構代碼(既沒有新增功能,也沒有修復 bug)
style:不影響程序邏輯的代碼修改(修改空白字符,補全缺失的分號等)
test:新增測試用例或是更新現有測試
revert:回滾某個更早之前的提交
chore:不屬於以上類型的其他類型
**/

module.exports = {extends: ['@commitlint/config-conventional']};  // 這裏使用@commitlint/config-angular默認配置

知識拓展

代碼規範標準 Airbnb 和 Standard

目前比較受歡迎的代碼規範有標準AirBnBStandard.AirBnb是Github上star人數是最多的,目前已經95k+了;而Standard的star人數有23k+。
網上很多都說Airbnb的規範比Standard更爲嚴格,那究竟是怎麼嚴格呢?
比較了一下二者的規則文檔,區別有:

  • Airbnb有接近160條的規則,而Standard有不到130條規則;
  • Airbnb默認是使用要分號;而Standard則默認不使用分號;
  • Standard的規則多是比較常見,易於理解和修改的格式或語法規範;而Airbnb規定得更爲具體和細緻,舉幾個例子大家感受一下:
  • const 和 let 都只存在於它定義的那個塊級作用域;
  • 當創建一個帶有動態屬性名的對象時,用計算後屬性名;
  • 不要直接調用Object.prototype上的方法,如hasOwnProperty, propertyIsEnumerable, isPrototypeOf;
  • 對象淺拷貝時,更推薦使用擴展運算符[就是…運算符],而不是Object.assign。獲取對象指定的幾個屬性時,用對象的rest解構運算符[也是…運算符]更好;
  • 用命名函數表達式而不是函數聲明;
  • 用默認參數語法而不是在函數裏對參數重新賦值;
  • Numbers: 用 Number 做類型轉換,parseInt轉換string常需要帶上基數;

附上Github鏈接地址可以查詢:
AirBnB(詳細可見AirBnb的中文版Github
Standard(詳細可見Standard的中文版Github

忽略校驗

對於規範中的規則,可以通過配置修改,也在代碼中可以使用註釋禁用ESLint規則檢測。
有幾種在代碼中禁用ESLint語法校驗的方式:

// 一、代碼塊
// 1:禁用代碼塊
/* eslint-disable */
	這裏被包裹的代碼語法不會被檢測
/* eslint-enable */

// 2: 沒有/* eslint-enable */,/* eslint-disable */後的所有代碼都會禁止規則校驗
/* eslint-disable */

// 3:註釋後禁用具體的規則,no-unneeded-ternary是三元運算,no-console是console輸出
/* eslint-disable no-console */ 
/* eslint-disable no-unneeded-ternary,no-console */ 

// 二、禁用下一行語法檢測("//"是包含在使用語句中的)
// 1:關閉下一行校驗
// eslint-disable-next-line 

// 2:禁用下一行具體的語法檢測
// eslint-disable-next-line no-alert 


// 三、關閉當前行的代碼語法檢測
// 1:關閉當前行的檢測
some code // eslint-disable-line

//2:針對當前行的某一具體規則禁用eslint檢查
some code // eslint-disable-line no-alert

相比較而言,AirBnB會更加嚴格,對很多具體的語法都進行了更爲嚴格的限制。對強規範代碼可能會使代碼看起來更優雅和統一,有更強的一致性,但是也會使你寫代碼受到更多的約束。
如果你的項目是後引入規範的項目,尤其是大項目來說,那就可能會讓人頭疼了。
所以對代碼的規範程度孰優孰劣,需要根據實際情況進行抉擇了。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章