[Vue進階]為(wèi)什麽我的(de)代碼讓别人看起來頭皮發麻？

ns868 2018-11-17 16:25:35 10457

前面的(de)話

首先我想說的(de)是，這篇文章(zhāng)不是介紹什麽高(gāo)深的(de)技術，請各位熟知。涉及的(de)都是日常開發當中一(yī)些不符合規範的(de)案例，借此分享給諸位。如(rú)果你是小白，或許這篇文章(zhāng)對你有點幫助，如(rú)果你是老司機，看完請輕點拍！有什麽建議或意見請留言斧正，謝謝！

有些同學(xué)在開發某個新功能時根據需求就哐哐哐（按照自(zì)己的(de)代碼風格）一(yī)頓撸。寫完發現，另一(yī)個地(dì)方也有這個模塊功能，可(kě)能隻是标題的(de)顔色，字體大小不對。怎麽辦？于是很雞賊的(de)複制粘貼過去(qù)，改吧(ba)改吧(ba)，提交代碼，萬事大吉！自(zì)己倒是爽了，功能是按照需求如(rú)期完成了啊，沒毛病。可(kě)是你卻忽視(shì)了一(yī)件很重要的(de)東西：團隊。

記住，你不是一(yī)個人在寫代碼。

這篇文章(zhāng)有别于其他教程類的(de)文章(zhāng)，不是教你如(rú)何制定代碼規範，也不是告訴你這樣寫就是錯的(de)亦或說是正确的(de)。本文是我這些天從優化别人代碼過程中的(de)所見和(hé)所得，凝結成文。旨在分享給大家，對号入座，然後改之。三人行，必有我師！；擇其善者而從之，其不善者而改之。 由于我是做(zuò)前端的(de)，所以隻說前端代碼規範，其他語言同樣适用！

目的(de)

把一(yī)些常見的(de)錯誤的(de)不良的(de)代碼示例分享給大家，希望有的(de)改之，無則加勉。看完之後，希望對你們有所幫助，提高(gāo)自(zì)己的(de)代碼質量，每個人都能寫出一(yī)手漂亮(liàng)的(de)代碼。這是這篇文章(zhāng)最大的(de)目的(de)了！

概述

本文将以我的(de)親身項目經曆為(wèi)例，來談談我們日常開發當中，就代碼層面來講，我們應該注意的(de)一(yī)些小細節。希望各位看客能吸取精華去(qù)其糟粕。主要涉及的(de)方面有：

項目結構
文件命名
路由
Vue 組件
JavaScript
Html
Css
Git 代碼提交

我将會從以上幾個方面逐一(yī)枚舉和(hé)大家分享讨論。

枚舉

1. 項目結構

沒說之前，您不妨看下自(zì)己的(de)項目結構是什麽樣的(de)。目前我們的(de)項目結構是這樣的(de)：

my-project ├── .idea                  # 這個是編輯器生成的(de) ├── build                  # Webpack 配置文件放在這裏 ├── config                 # Vue 基本配置文件放在這裏 ├── node_modules           # 第三方依賴 ├── src                    # 項目源碼（核心文件） │   ├── assets             # 資源文件（js, css, scss） │   ├── components         # 所有組件 │   ├── js                 # 自(zì)己寫的(de) js，裏面各種工具類方法等 │   ├── mixins             # 混合 │   ├── router             # 路由 │   ├── vuex               # 狀态管理(lǐ) │   ├── App.vue            # 根組件 │   └── main.js            # 入口文件 ├── static                 # 靜态資源，一(yī)般放 img ├── theme                  # 主題文件，修改的(de) Element-UI 主題 ├── .babelrc               # babel 編譯配置 ├── .editorconfig          # 代碼格式 ├── .gitignore             # Git 提交忽略的(de)文件配置 ├── .postcssrc.js          # 轉換 css 的(de)工具配置文件 ├── element-variables.css  # Element 全局定義的(de)變量，不明白為(wèi)啥放這兒 ├── index.html             # 主頁模闆 ├── package-lock.json      # 用來鎖定依賴的(de)版本号（NPM 自(zì)動生成） ├── package.json           # 項目基本信息 └── README.md              # 項目介紹 複制代碼

都是用 vue-cli 生成的(de)，目錄結構和(hé)命名規範也就沒啥可(kě)說的(de)。可(kě)能随着時間的(de)推移，自(zì)己會在項目裏加一(yī)些東西（文件或文件夾）。拿上面我們的(de)項目為(wèi)例來說幾點吧(ba)：

比如(rú) element-variables.css 文件，雖然這個文件是 Element自(zì)定義主題自(zì)動生産的(de)，但是可(kě)以通過配置更換生成所在目錄。因為(wèi)它屬于 theme 文件夾下的(de)東西，所以應該放它下面的(de)。

js 文件夾應該命名為(wèi) utils：

因為(wèi)它對外暴露的(de)都是工具類方法，這樣更顯語義化。

關于項目結構，我發現的(de)就這麽多。每個項目的(de)目錄可(kě)能會不同，這個就看你們的(de)規範了。

2. 文件的(de)命名

它包含文件的(de)命名和(hé)文件夾的(de)命名。依我們的(de)項目為(wèi)例，我重點說下 src/components 目錄下的(de)命名，真的(de)是五花八門：

2.1. 文件名不夠語義化

這個還算正常，但還是有些問題。這裏是一(yī)些問題清單：

這個模塊的(de)中文叫，是關于機器人學(xué)習的(de)，叫 knowledgeBaseManagement 雖然很好的(de)翻譯了中文意思，但總覺的(de)有點長(cháng)，叫 robot 會不會好些？
而且文件夾下的(de)文件命名也不夠語義化

下面是整理(lǐ)過後的(de)樣子(zǐ)：

robot ├── addQuestion.vue ├── editQuestion.vue ├── index.vue └── missedQuestion.vue 複制代碼

這個我就不想說了，看的(de)我頭皮發麻。從字面意思上來講，我就認識一(yī)個 TreeNode2.vue。後面還加個 2 是什麽鬼？

2.2. 文件目錄不統一(yī)

這屬于一(yī)類問題，即裏面太亂了，不統一(yī)，問題清單：

src/components/moduleName/ 下除了子(zǐ)模塊外，盡量不要瞎放其他無關的(de)文件夾，如(rú)上面的(de) src、component/common、top
callcenterList/src 下的(de)圖片可(kě)以放到 static 下
如(rú)果是功能型組件（上面的(de) color 是一(yī)個顔色選擇器組件），盡量放到一(yī)個叫 package 或者 lib 的(de)文件夾下。因為(wèi) src/components 下的(de)模塊都是系統模塊，不要混淆。
elvesSetting/top 如(rú)果是某幾個頁面頭部的(de)公共部分盡量放到 components/common 下

2.3. 文件名過長(cháng)

如(rú)果一(yī)個模塊下就一(yī)個文件，盡量寫成 index.vue 。這裏文件夾和(hé)文件同名，路由是不是很長(cháng)？你在其他文件中 import 的(de)時候是不是也不方便？而且我發現 problemManagement 和(hé) problemRetrieve 都屬于問題管理(lǐ)模塊，完全可(kě)以合并到一(yī)個文件夾裏啊。還有，文件夾已經表明是問題管理(lǐ)模塊了，所以文件名就不要再以 problem*** 開頭了。不覺得啰嗦嗎？下面是整理(lǐ)過後的(de)樣子(zǐ)：

problemManagement │   ├── index.vue │   ├── retrieve.vue qualityCheckAppeal     └── index.vue 複制代碼

3. 路由

我們系統裏的(de)路由都是一(yī)級路由。舉個栗子(zǐ)：

userManagement ├── add.vue └── update.vue 複制代碼

用戶管理(lǐ)下有增改兩個功能，不使用彈框去(qù)做(zuò)的(de)前提下，假如(rú)說 add 和(hé) update 對應兩個路由是 /addUser，/updateUser。我們系統地(dì)址欄是這樣顯示的(de)：

// 增加用戶 localhost:3030/addUser // 修改用戶 localhost:3030/updateUser?id=1 複制代碼

雖然地(dì)址欄路由短(duǎn)看起來會讓人舒服，但是模塊多的(de)話，就不容易區分，其實應該這樣做(zuò)：

// 增加用戶 localhost:3030/user/add // 修改用戶 localhost:3030/user/update?id=1 ... // 總結 localhost:3030/module/function?queryString 複制代碼

當然也可(kě)以使用最近流行的(de) RESTful API 設置規範，專門用于 Web 數據結構的(de)設置。阮一(yī)峰老師有一(yī)篇非常不錯的(de)文章(zhāng)，推薦給大家，我就不再贅述辣。傳送門->

4. Vue 組件

關于 Vue 組件開發規範可(kě)以參考官方的(de)風格指南。下面是我們項目的(de)一(yī)些問題清單和(hé)改正意見，我列舉一(yī)下作為(wèi)對照：

不要在 App.vue 中直接修改第三方樣式（比如(rú)：ElementUI）。請使用外部文件導入：

App.vue 文件：

<!-- incorrect --> ... <style>   .el-input__icon {     cursor: pointer   } </style> <!-- correct --> ... <style>   @import 'element-style-overwrite';   ... </style> 複制代碼

_element-style-overwrite.scss 外部樣式文件：

.el-input__icon {   cursor: pointer } 複制代碼

給每個組件起個名字是個好習慣。例如(rú) Dialog 組件：

// incorrect export default {   ... } // correct export default {   name: 'MyDialog', // 以大駝峰命名   ... } 複制代碼

給組件樣式設置作用域 scoped

如(rú)果你在某個子(zǐ)組件中修改了全局樣式，本來隻想在該組件中使用，沒想到造成了全局污染。等進行代碼 review 的(de)時候是很難排查的(de)。

例如(rú)，用戶管理(lǐ)（UserManagement.vue）組件：

<style scoped> ... </style> 複制代碼

組件名要麽單詞大寫開頭 (PascalCase)，要麽橫線連接(kebab-case)：

// incorrect components/ └── mycomponent.vue components/ └── myComponent.vue // correct components/ └── MyComponent.vue // 或者 components/ └── my-component.vue 複制代碼

.vue 單文件中的(de) <template>、<script>、<style> 标簽的(de)順序問題

有的(de)人喜歡這樣寫：

<style>...</style> <template>...</template> <script>...</script> 複制代碼

也有人喜歡這樣寫：

<script>...</script> <style>...</style> <template>...</template> 複制代碼

如(rú)果你想寫，那好，不阻攔，拜托你統一(yī)下行不？别這個組件這個順序，那個組件那個順序。累不累？這裏我強力推薦大家按照官方的(de)寫法，即下面的(de)順序來寫：

<template>...</template> <script>...</script> <style scoped>...</style> 複制代碼

組件中的(de)字體圖标（icon）不要用 png 圖片

不知道(dào)你們項目裏有沒有很多 icon 圖标。反正我們項目不少且都是 png 圖片。靜态文件夾裏好多小圖标。本來左側菜單也都是 png 圖标的(de)，被我看着不爽重構了一(yī)下。把所有的(de) png 圖标換成了 fontIcon 字體。

字體圖标的(de)優勢：

減少 http 請求和(hé)項目體積
樣式容易控制
用戶體驗好

如(rú)何制作 fontIcon 字體圖标呢(ne)？其實很簡單：

1、可(kě)以先去(qù)阿裏圖庫找自(zì)己喜歡的(de)或者讓你自(zì)己家的(de)UI小姐姐做(zuò)。
2、下載 svg 格式的(de)，如(rú)果是UI做(zuò)的(de)，記得讓她轉換下。
3、去(qù) icomoon 字體圖标生成網站導入剛才所有的(de) svg 圖标，設置字體名稱導出即可(kě)。
4、再在文件中引用，大功告成。
使用兩個空格（space）進行縮進

這個放在全局規範會比較好一(yī)些。為(wèi)什麽是兩個空格？大神們都是這樣做(zuò)的(de)！而且更重要的(de)是，使用兩個空格開發項目，傳到 github 或者 gitlab 上排版會很好看。什麽？不會設置？百度啊！你用的(de)什麽編輯器就查這個編輯器怎麽設置的(de)。

一(yī)般是統一(yī)把全局規範設置放到一(yī)個叫 .editorconfig 的(de)文件夾裏，有的(de)編輯器支持這個文件，比如(rú)：webstorm。有的(de)則不支持，對于不支持的(de)編輯器，可(kě)以下載安裝 editorConfig 插件，如(rú)：atom、sublime、vscode 等。

代碼中不用的(de)注釋都删掉
調試結束，把不用的(de) console.log(...) 及時删掉，它會影響性能
data 中的(de)屬性命名和(hé)初始化問題

// incorrect export default {   data () {     return {       text: 'wwwwwwww', // 這是啥？       editBoxId: null, // 很明顯Id是String，這裏他初始化一(yī)個 null       flag: '',    // 這個表示的(de)啥？看意思應該是個 Boolean 類型，為(wèi)啥弄個 String ?       pSize: 10,   // pSize 是啥？       cPage: 1,    // cPage 是啥？       popCsr:true, // popCsr 是啥，恐怕現在連那個開發者自(zì)己都不知道(dào)了吧(ba)       callcenterAuthority: false, // 這麽長(cháng)你告訴是一(yī)個 Boolean 類型的(de)     }   } } // correct export default {   data () {     return {       text: '', // 'wwwwwwww' 沒卵用删掉       editBoxId: -1,  // 它應該是個 Number 類型       flag: false,    // 它應該是個 Boolean 類型啊       pageSize: 10,   // pSize -> pageSize 多好       currentPage: 1, // 完整寫法更易懂，不是嗎？       isPopcsr: true,    // Boolean 類型的(de)總是前面加個 is       isAuthority: false, // 是否授權。     }   } } 複制代碼

其實還有好多問題，我就不一(yī)一(yī)列舉了。諸如(rú)此類的(de)問題，希望各位看客們都能吸取精華，去(qù)其糟粕。

Props 中的(de)屬性聲明要明确類型

// incorrect export default {   props: ['node', 'size'] } // correct export default {   props: {     node: Object, // 對象     size: [String, Number], // 兩種類型都可(kě)以   } } 複制代碼

Vue 生命周期函數按順序放在 methods 之前

為(wèi)什麽說這個呢(ne)？我們項目中有的(de)組件就 methods 中的(de)代碼就上千行。如(rú)果生命周期函數放在 methods 之後，拉來拉去(qù)非常不方便：

// incorrect export default {   ...   created () {},   methods: {     // 省略 1000 行代碼     // ...   },   mounted () {},   beforeDestroy () {},   destroy () {}, } // correct export default {   ...   created () {},   mounted () {},   beforeDestroy () {},   destroy () {},   methods: {     // 省略 1000 行代碼     // ...   } } 複制代碼

Vue 組件中的(de) this 賦值要統一(yī)

代碼中，有時候我們需要把 this 賦給一(yī)個變量，你要麽統一(yī)賦值給變量 vm ，要麽統一(yī)賦值給變量 self。别一(yī)個組件裏，變來變去(qù)。

// incorrect export default {   ...   methods: {     one () {      let vm = this     },     two () {       let self = this     }   } } // incorrect export default {   ...   methods: {     one () {      let vm = this      // 或者      let self = this     },     two () {       let vm = this       // 或者       let self = this     }   } } 複制代碼

Vue 組件中 Html 如(rú)果過長(cháng)，請換行

<!-- incorrect --> <el-input v-model="ruleForm.maskInput" size="small" class="nodeIpt" :icon="ruleForm.maskInput ? 'circle-close':''"  @click="ruleForm.maskInput = ''" @keyup.enter.native="nodesure($event,'ruleForm')"></el-input> <!-- correct --> <el-input    v-model="ruleForm.maskInput"    size="small"    class="nodeIpt"    :icon="ruleForm.maskInput ? 'circle-close':''"     @click="ruleForm.maskInput = ''"    @keyup.enter.native="nodesure($event,'ruleForm')"> </el-input> 複制代碼

Vue 中監聽的(de)事件記得垃圾回收

舉個例子(zǐ)，如(rú)果我們在 Vue 組件的(de) created 聲明周期鈎子(zǐ)中監聽了一(yī)個點擊事件，那麽，當組件銷毀（beforeDestroy）之前記得把這個事件釋放，看代碼：

export default {   ...   created () {     document.addEventListener('click', this.handleClick)   },   beforeDestroy () {     document.removeEventListener('click', this.handleClick)   } } 複制代碼

Vue 組件中不要直接操作異步請求（axios）

把所有的(de)異步請求方法封裝成一(yī)個獨立 js 文件，或者放到 Vuex 中，千萬不要耦合到 Vue 組件中。因為(wèi)代碼量太多，會加重組件的(de)後期維護，各司其職不好嗎？

不好的(de)範例：

// User.vue export default {   ...   mounted () {     this.getUsers()   },   methods: {     getUsers () {       this.axios(url, data, (response) => {         // Do something       }).catch(err => {         console.error(err)       })     }   } } 複制代碼

如(rú)果項目比較小還好，我沒意見，如(rú)果項目較複雜，千萬别這麽幹。下面是推薦的(de)做(zuò)法：

// server.js // 專門處理(lǐ)數據請求的(de)文件，也就是我沒常說的(de)MVC中的(de) M 層 import axios from 'axios' export default {   /**    * 獲取用戶列表    */    getUsers (url, data) {       return axios.get(url, data)    } } // User.vue import api from '@/api/server.js' export default {   ...   data () {     return {       users: null     }   },   mounted () {     api.getUsers((response) => {       this.users = response.data.data     }).catch(err => {       console.log(err)     })   } } 複制代碼

5. JavaScript

下面所有的(de)錯誤代碼示例都是從我們的(de)項目中發現的(de)，撿主要的(de)列出來一(yī)些。希望犯同樣錯誤的(de)你能及時改正哦~

變量命名

要語義化命名

// incorrect var a = document.getElementById(this.lastid) // 這裏的(de) a var aa = true // 這是啥你們知道(dào)嗎？ // corrent let orderId = this.order.id let currentTime = Date.now() 複制代碼

多個單詞要駝峰命名

// incorrent vm.timedefault = timedvalue vm.currentsessionid = id // corrent vm.timeDefault = timedValue vm.currentSessionId = id 複制代碼

變量要加注釋

上面那一(yī)坨你們知道(dào)啥意思嗎？如(rú)果這個開發人員離(lí)職了，那可(kě)是坑了後來人了。所以，做(zuò)開發不能自(zì)己爽了，做(zuò)一(yī)個帥氣和(hé)代碼于一(yī)身的(de)工程師，難道(dào)不更好嗎？

不要重複使用 var 聲明變量

// incorrect var name = 'test'; var age = 12; var hobby = 'sport'; // correct var name = 'test',   age  = 12,  hobby = 'sport'; 複制代碼

= 或 == 之間要保留一(yī)個空格

錯誤的(de)範例：

// 變量 var name='test' var arr=[] var obj={   id:1 } // if 判斷 if(this.id==currentId){   // Do something } // for 循環 for(let i=0;i<arr.length;i++){   // Do something } 複制代碼

上面三種情況是最常見的(de)，其他雷同。下面是正确的(de)範例：

// 變量 var name = 'test' var arr = [] var obj = {   id: 1 } // if 判斷 if(this.id == currentId) {   // Do something } // for 循環 for(let i = 0; i < arr.length; i++) {   // Do something } 複制代碼

右括号 ) 遇到左大括号 { 時要空一(yī)格

下面是錯誤的(de)範例：

// if if(a === b){   // Do something } // for for(let i = 0; i < arr.length; i++){...} // 函數 var T = function(params){   ... } 複制代碼

常見的(de)幾種情況，其他情況不再列舉。下面是正确的(de)範例：

// if if (a === b) {   // Do something } // for for (let i = 0; i < arr.length; i++) {...} // 函數 var T = function(params) {   ... } 複制代碼

非空判斷問題

在我們項目裏，有人這樣寫：

// 假如(rú) Vue 組件中有一(yī)個叫 userId 的(de) data 屬性 if (userId != '' || userId != 0 || userId != false || userId != null || userId != undefined) {   // ... } 複制代碼

當遇到上面幾種情況的(de)時候，下面代碼實現的(de)效果是一(yī)樣的(de)：

if (!userId) {   // ... } 複制代碼

對象聲明問題

不要用下面的(de)方式之一(yī)去(qù)聲明一(yī)個對象：

// incorrect var arr = new Array() // 數組 var arr = '' // 雖然 js 是弱類型，也不能這樣聲明 var obj = new object() // 對象 var obj = '' 複制代碼

下面是推薦做(zuò)法，也是大衆做(zuò)法：

// 聲明數組 let arr = [] // 聲明對象 let obj = {}  // or let obj = null 複制代碼

異常處理(lǐ)問題

我們在處理(lǐ)異步請求的(de)時候，一(yī)定要對 response 中的(de)數據進行異常處理(lǐ)，不然控制台回報 response.data is not undefined，我們項目我看了下，有些地(dì)方沒做(zuò)處理(lǐ)，結果在做(zuò)測試的(de)時候，浏覽器控制台一(yī)頓報錯。那叫一(yī)個難看啊！

// incorrect this.axios(url, data, (response) => {   let result = response.data.data }) // correct this.axios(url, data, (response) => {   if (response.data && response.data.code === 1) {     let result = response.data.data   } }).catch(err => {   console.error(err) }) 複制代碼

如(rú)果這個取值過長(cháng)且多次用到，請賦給一(yī)個變量

export default {   ...   methods: {     handleClick (evt) {       // incorrect       evt.target.parentNode.innerHTML = 'test'       evt.target.style.width = '100px'       evt.target.style.height = '200px'              // correct       let target = evt.target       target.parentNode.innerHTML = 'test'       target.style.width = '100px'       target.style.height = '200px'     }   } } 複制代碼

6. HTML

正确的(de)使用标簽

項目中我見有人寫個按鈕居然用 span 标簽，或者一(yī)個 div 。

下面是錯誤的(de)範例：

// 用 div 當按鈕 <div class="btn">搜索</div> // 在 span 裏 嵌套 el-input 組件 // 這樣做(zuò)的(de)同學(xué)，肯定不知道(dào) el-input 編譯後的(de)代碼是啥樣的(de)！ <span>   <el-input></el-input> </span> // 用 label 當标題 // label 标簽是配合表單使用的(de) <label>标題</label> // 加粗字體沒有用原生标簽 <span class="bold">我是加粗字體</span> 複制代碼

下面是改正後的(de)範例：

// 用 H5 的(de) button <button class="btn">搜索</button> // 如(rú)果要包含 el-input 組件請使用塊級元素，并加上合适的(de) class <div class="el-input__wrapper">   <el-input></el-input> </div> // h1-h6 才是标題的(de)正确打開方式 <h2>标題</h2> // 加粗字體請使用原生标簽 // 然後使用 class 控制字體樣式 <strong class="bold">我是加粗字體</strong> 複制代碼

所有的(de)按鈕，超鏈接，鼠标的(de) :hover 狀态都應該是手形。

a, button {   cursor: pointer } 複制代碼

id 和(hé) class 或者其他的(de)屬性，命名要語義化

不要命個名隻有你自(zì)己知道(dào)。這樣會帶來後期維護困難。

<!-- incorrect --> <div class="dfdf">   <el-form class="loginForm">...</el-form> </div> <!-- correct --> <div class="login-form__wrapper">   <el-form class="loginForm">...</el-form> </div> 複制代碼

把代碼縮進改成 2 個空格
Html 中的(de)屬性之間保留一(yī)個空格距離(lí)

<!-- incorrect --> <el-input v-model="form.loginUser"  size="small"   placeholder="請輸入用戶名"></el-input> <!-- 不覺的(de)上面的(de)代碼很醜嗎，我知道(dào)你或許不會這樣做(zuò) --> <!-- 但還真有人這樣做(zuò) --> <!-- 下面是改進後的(de)代碼 --> <el-input v-model="form.loginUser" size="small" placeholder="請輸入用戶名"></el-input> 複制代碼

每個代碼快盡量加上注釋

代碼量少尚且不說，如(rú)果一(yī)個 .vue 文件很長(cháng)的(de)話，找起來就很痛苦了。你還别說，我們項目裏就是這樣沒注釋。

<!-- 正确的(de)示範 --> <template>   <div class="user-managerment__wrapper">     <!-- Header -->     <div class="header">...</div>          <!-- User table -->     <div class="user-table__wrapper">       <el-table>...</el-table>     </div>          <!-- Add user dialog -->     <div class="add-user__dialog">       <el-dialog title="新增用戶">...</el-dialog>     </div>   </div> </template> 複制代碼

7. CSS

{ 和(hé)選擇器保持一(yī)個空格距離(lí)

.selector {   ... } 複制代碼

給每個樣式模塊加上注釋有助于區分

// Global style html, body, a, div {   margin: 0 } // Login style .login button {   ... } // User manager style .user-manager__wrapper {   ... } 複制代碼

每個獨立樣式間保留一(yī)行距離(lí)

見上面的(de)示例

選擇器不要嵌套太多層級

嵌套太多層級會影響性能，盡量保證在三層以下：

// incorrect .user-management .user-box .user-form .el-form-item .remark {   color: #42b983 } // correct .user-management .user-form .remark {   color: #42b983 } 複制代碼

8. Git 代碼提交

提交前先 pull 代碼

寫代碼前記得先 pull 下别人的(de)代碼，這是個好習慣。别等到自(zì)己寫完 push 後才發現代碼有沖突。

# pull git pull # modified git add someFiles git commit -m "..." git push 複制代碼

寫好提交注釋

大家可(kě)以看我沸點。同事寫的(de)注釋。希望有問題的(de)同學(xué)可(kě)以及時改正哦。另外，關于 Git 如(rú)何正确的(de)寫好注釋，這裏有幾篇文章(zhāng)講的(de)很好，大家可(kě)以看看：

下面舉個例子(zǐ)，比如(rú)我這次在用戶管理(lǐ)模塊中修改了兩個 bug。如(rú)何以清單的(de)方式提交呢(ne)？看代碼：

# add file git add src/components/userManager/index.vue # commit git commit -m 'fix: 用戶管理(lǐ)模塊bug修改。 修改內(nèi)容： - 修改了列表分頁的(de)bug - 修改了當用戶點擊編輯按鈕彈框無法顯示的(de)bug ' # push code git push 複制代碼

你千萬别用下面的(de)方式之一(yī)去(qù)提交你的(de)代碼說明：

# 說一(yī)些毫無意義的(de)內(nèi)容 git commit -m "fix: ok!" # or 不加 fix、feat、refactor、doc、style等前綴 # 為(wèi)什麽要加這些前綴呢(ne)？問得好！ # 是方便日後檢索，當我們以這些前綴去(qù)搜索修改日志的(de)時候 # 是很容易的(de)哦，微笑。 git commit -m "修改用戶模塊bug"

編輯:--ns868

南順網絡