提高開發效率之命名規範

對於變量命名，以前作開發的時候不太注意，以爲只是起個名字這麼簡單而已。但命名的時候也會糾結不少問題，不知道該用什麼單詞，往數據庫添加數據的時候用create仍是add，對話框使用model仍是用dialog，有時候甚至不知道怎麼起名字。

首先列舉幾個不規範的命名

1. 隨意使用簡寫

<div class="search-form form-inline edit-form x-ac-he"> <!-- x-ac-he是什麼樣的類名 --> ... </div>

data = { mulSel:[], // mul表示多個，sel一眼看上去不知道是啥
    chooseCate:0, // Cate 不知道是啥
    total:0 // 知道total表示總共，多是統計數據長度，但具體表示什麼長度不知道
}

<ask-remove :callback="fetchData" :url="orgApi.delete"> <!-- ask-remove 詢問刪除？表示刪除確認對話框，用delete-confirmation, fetchData，獲取數據？ -->
    <strong v-text="selected.cOrg_Name"></strong>
</ask-remove>

2. 變量名稱意思不明確，容易誤解

用total表示總數，單具體表示什麼總數，要翻遍代碼找找total具體指向。fetchData，不知道獲取什麼數據集。orgs()，若是不是後面帶個括號都不知道是要幹嗎。showButton返回true/false

3. 不明確的狀態標示

scope.row.parent != 0， scope.row.authorityType == 1 不知道0，1具體表明的是什麼，也沒有註釋。就算有註釋，也不容易記住

4. 錯誤的命名方法

用selected表示選中的對象集，用showDialog表示彈出框的狀態，常量用小駝峯命名

以上是以往項目裏犯過錯誤的地方，由於以前都是一我的寫代碼比較多，偶爾碰到修改別人代碼的時候會發現改起來很費勁。不敢動。另外不多對以前的項目作維護，通常都是一次性的。

命名規範的好處：

　　可讀性高，不用看註釋就能知道一個變量，方法是用來幹嗎的，對整個代碼，業務理解起來比較容易

　　提高開發效率，便於共享和協同開發，不須要一個一個去問別人寫的是什麼

　　下降維護成本，讀起來都很費勁的代碼，維護起來天然不易

 

具體作法

1，單詞拼寫要正確

　　這是最低級的錯誤，若是單詞都不能拼寫正確，時間長了本身可能會遺忘，更容易形成語法的上錯誤。別人可能都不知道你寫的什麼，有時候還要去靠猜。 這是最讓人頭疼的

2，使用簡介明確含義的英文單詞，詞組

　　不使用漢語拼音，中英混寫

　　儘可能使用業務上便於理解的單詞，不少時候項目小組的溝通不是區分變量，函數，類，接口這些技術上的溝通，更多的是業務上，數據上的溝通。使用users/userlist，比使用useArr更能表示一組用戶集

　　避免不明因此的簡寫，可使用簡寫，但要用你們共識的那些簡寫。org - organization, btn - button, str - string。最好不使用簡寫，這樣代碼更容易閱讀。

3，正確選擇不一樣類型命名的方式

　　變量，屬性命名使用名詞，名詞詞組或形容詞+名詞組合。

　　數組，統一使用名詞的複數形式，或者名詞+list，最好只用一種方式

　　對象，使用單數形式的名詞+Info，或單數名詞。見過有人用名詞+Repository

　　狀態，通常值爲布爾類型，使用形容詞表示狀態。selected 是否選中，loading 正在加載。能夠在形容詞前加is/if/has

　　方法，使用動詞+名詞、名詞詞組。getUsers, getSelectedOrg

　　限定命名，表示名詞的最大，最小，總數等，用名詞+限定詞，把重要的名詞放前面；如userTotal, userAccount, stringLength

4， 約定好經常使用的命名單詞，詞組

　　CSS 固定命名規則，BEM命名規則

　　JS 經常使用命名

5， 命名方法

　　變量，方法使用小駝峯(lowerCamelCase)命名

　　局部變量，方法使用方法名後加下劃線 this.addUser_, this.user_

　　類名，組件，接口引用使用大駝峯（UpperCamelCase）命名

　　枚舉，常量使用大駝峯（UpperCamelCase），而且單詞之間用下劃線（_）分割

　　參數使用小駝峯(lowerCamelCase)命名，若是參數是第三方類庫，能夠在參數名前加類庫的標示符。如引用jquery 

最後：想要提升代碼質量，仍是要常常去看下開源代碼，欣賞學習別人是如何約定命名規則和編寫代碼的。另外作爲程序員要時刻保持一份review 本身代碼的心，不斷的重構和修改精進本身的代碼。

附上 google 的代碼規範，不限於命名規範