有人說，命名能力也能體現(xiàn)一個程序員的基本編程素養(yǎng)。我很贊成這句話！作為開發(fā)人員逃不過起名字這一關(guān)的,大到項目名、模塊名，小到類名、方法名、參數(shù)名、參數(shù)名、變量名。而命名又對代碼的質(zhì)量和可讀性起到很關(guān)鍵的決定。

如何碼出高質(zhì)量的代碼呢？其實命名也沒有那么難，關(guān)鍵看你重不重視，愿不愿意花時間。以下是課程筆記和阿里巴巴的開發(fā)手冊中覺得適用的部分，分享出來。

課程筆記

• 命名多長最合適？

命名的一個原則能夠準確的表達其含義即可。命名可以長點也沒關(guān)系。

• 命名要可讀、可搜索

這里說的可讀，指的是不用用一些特別生僻的英文單詞來命名。可搜索是利用開發(fā)工具的智能聯(lián)想功能。比如鍵入獲取某個對象“.Get”,IDE就會返回所有以Get開頭的方法等等。例如：

獲取單個對象的方法用Get做前綴

獲取多個對象的方法用GetList做前綴

獲取多個對象的方法用Getcount做前綴

插入的方法用 save/insert 做前綴

刪除的方法用 remove/delete 做前綴

修改的方法用 update 做前綴

• 函數(shù)多大才合適？

一個函數(shù)幾百行，說明了什么？邏輯過于復雜、閱讀代碼的時候，很容易就會看了后面忘了前面。其實更能反映一個程序員的邏輯能力和提煉能力！要本著函數(shù)單一職責原則，進行合理的拆分！具體函數(shù)大小也沒法量化，網(wǎng)上有一種說法，那就是不要超過一個顯示屏的垂直高度。大概函數(shù)也是50行左右。

• 注釋如何寫？命名很重要，注釋跟命名同等重要。有人認為好的命名完全可以代替注釋。個人覺得，這樣的觀點有點太過極端。命名再好，畢竟有長度限制，不可能足夠詳盡，這個時候，注釋就是一個很好的補充。注釋的目的是讓代碼更容易看懂。

阿里開發(fā)手冊命名、注釋部分（稍有改動）

• 【強制】代碼中的命名嚴禁使用拼音與英文混合的方式，更不允許直接使用中文的方式。說明：正確的英文拼寫和語法可以讓閱讀者易于理解，避免歧義。注意，即使純拼音命名方式也要避免采用。

• 【強制】類名、方法名使用 UpperCamelCase 風格，但以下情形例外：DO / BO / DTO / VO / ?UID 等。

• 【強制】參數(shù)名、成員變量、局部變量都統(tǒng)一使用 lowerCamelCase 風格，必須遵從駝峰形式。

• 【強制】常量命名全部大寫，單詞間用下劃線隔開，力求語義表達完整清楚，不要嫌名字長。

• 【強制】抽象類命名使用 Abstract 或 Base 開頭；異常類命名使用 Exception 結(jié)尾；測試類命名以它要測試的類的名稱開始，以 Test 結(jié)尾。

• 【強制】杜絕完全不規(guī)范的縮寫， 避免望文不知義。反例：AbstractClass“縮寫” 命名成 AbsClass；condition“縮寫” 命名成 condi，此類隨 意縮寫嚴重降低了代碼的可閱讀性。

• 【推薦】如果模塊、 接口、類、方法使用了設計模式，在命名時需體現(xiàn)出具體模式。說明：將設計模式體現(xiàn)在名字中，有利于閱讀者快速理解架構(gòu)設計理念。

• 【參考】枚舉類名建議帶上 Enum 后綴，枚舉成員名稱需要全大寫，單詞間用下劃線隔開。

說明：枚舉其實就是特殊的類， 域成員均為常量， 且構(gòu)造方法被默認強制是私有。

注釋規(guī)約

• 【強制】所有的抽象方法（包括接口中的方法）注釋，除了返回值、參數(shù)、 異常說明外，還必須指出該方法做什么事情，實現(xiàn)什么功能。

說明：對子類的實現(xiàn)要求，或者調(diào)用注意事項，請一并說明。

• 【強制】所有的類都必須添加創(chuàng)建者和創(chuàng)建日期。

• 【強制】方法內(nèi)部單行注釋，在被注釋語句上方另起一行，使用//注釋。方法內(nèi)部多行注釋使用/* */注釋，注意與代碼對齊。

• 【強制】所有的枚舉類型字段必須要有注釋，說明每個數(shù)據(jù)項的用途。

• 【推薦】與其“半吊子”英文來注釋，不如用中文注釋把問題說清楚。專有名詞與關(guān)鍵字保持英文原文即可。反例：“TCP 連接超時”解釋成“傳輸控制協(xié)議連接超時”，理解反而費腦筋。

• 【推薦】代碼修改的同時，注釋也要進行相應的修改，尤其是參數(shù)、返回值、異常、核心邏輯等的修改。說明：代碼與注釋更新不同步，就像路網(wǎng)與導航軟件更新不同步一樣，如果導航軟件嚴重滯后，就失去了導航的意義。

• 【參考】對于注釋的要求：第一、能夠準確反應設計思想和代碼邏輯；第二、能夠描述業(yè)務含義，使別的程序員能夠迅速了解到代碼背后的信息。完全沒有注釋的大段代碼對于閱讀者形同天書，注釋是給自己看的，即使隔很長時間，也能清晰理解當時的思路；注釋也是給繼任者看的，使其能夠快速接替自己的工作。

• 【參考】好的命名、代碼結(jié)構(gòu)是自解釋的，注釋力求精簡準確、表達到位。避免出現(xiàn)注釋的一個極端：過多過濫的注釋，代碼的邏輯一旦修改，修改注釋是相當大的負擔。

最后，還有一條非常重要的，那就是，項目、團隊，甚至公司，一定要制定統(tǒng)一的編碼規(guī)范，并且通過 Code Review 督促執(zhí)行，這對提高代碼質(zhì)量有立竿見影的效果。

創(chuàng)作挑戰(zhàn)賽新人創(chuàng)作獎勵來咯，堅持創(chuàng)作打卡瓜分現(xiàn)金大獎

總結(jié)

以上是生活随笔為你收集整理的优秀的开发者从命名开始的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。