1 代碼規(guī)范化的意義

　　1.1軟件維護(hù)是軟件生命周期中持續(xù)時(shí)間最長的階段。因此代碼總會被很多人去維護(hù)，規(guī)范的代碼可以減少維護(hù)人員的理解時(shí)間，降低維護(hù)代價(jià)，方便進(jìn)行二次開發(fā)

　　1.2幾乎沒有任何一個(gè)軟件，在其整個(gè)生命同期中，均由最初的開發(fā)人員來維護(hù)，所以作為最初的你最好留下好的口碑

　　1.3編碼規(guī)范可以改善軟件的可讀性，可以讓程序員盡快而徹底地理解新代碼

　　1.4建議性的規(guī)范幫助編碼人員寫出易理解、易維護(hù)、易擴(kuò)展的優(yōu)秀代碼

2 編碼規(guī)范指南

　　2.1排版規(guī)范

　　　　2.1.1程序塊采用縮進(jìn)，縮進(jìn)空位為4個(gè)

　　　　2.1.2分解符如“{”和“}”獨(dú)占一行，并且位于同列

　　　　2.1.3較長的語句、表達(dá)式、參數(shù)要書寫多行

　　　　2.1.4一行只寫一條語句

　　　　2.1.5if,for,do,while,case,switch,default 獨(dú)占一行，且語句塊都要加“{ }”,無論語句多少

　　　　2.1.6相對獨(dú)立的業(yè)務(wù)語句塊之間，變量說明后加空行

　　　　2.1.7對齊只用空格不用TAB，避免不同編輯器對TAB處理不同

　　　　2.1.8對二個(gè)以上的關(guān)鍵字、變量、常量進(jìn)行對等操作時(shí)，變量前后必須留空格，如果if( a == b)

　　　　2.1.9類屬性和方法不用交叉放置，不同存取范圍的屬性或方法也不遠(yuǎn)交叉放置

　　2.2注釋規(guī)范

　　　　2.2.1有代碼的地方就有注釋，杜絕沒有任何注釋的代碼，推薦注釋量在20%以上

　　　　2.2.2包的注釋：在包的當(dāng)前路徑放入一名為package.html的HTML文件，方面JavaDoc收集。注釋內(nèi)容簡述本包的作用、內(nèi)容、產(chǎn)品模塊、版本、版權(quán)等

　　　　2.2.3文件注釋：文件開始，package 關(guān)鍵字前面，記載版權(quán)說明、描述信息、生成日期、修改歷史

　　　　2.2.4類和接口的注釋：在package之后，class或interface之前，描述當(dāng)前類或接口的功能，作者，生成日期，修改日志，版本號等

　　　　2.2.5類屬性、方法注釋：在類或方法的前面，類屬性記載屬性的功能用處，用/* 開頭描述注釋，放置JavaDoc收集；

　　　　2.2.6類方法注釋需要記載方法的功能簡述、詳細(xì)、輸入?yún)?shù)、輸出值、拋出的異常、作者等

　　　　2.2.7類方法內(nèi)部注釋： 注釋應(yīng)放置被注釋語句的正上方或右側(cè)； 注釋必須與被注釋的語句同縮進(jìn)； 注釋與上面的代碼只有用一個(gè)空行隔開； 屬于同一業(yè)務(wù)邏輯塊的代碼，須顯示注釋用途； 對于變量定義和分支語句（if, switch, case）必須注釋； 寫代碼的同時(shí)寫注釋，修改代碼的同時(shí)，也修改注釋； 注釋塊內(nèi)部請不要加縮進(jìn)； 注釋內(nèi)容內(nèi)部需要著重提示的，請包括標(biāo)簽<b>xxxx</b> 對于業(yè)務(wù)邏輯比較多的方法，建議顯示注釋步驟1、2,、3、4… 注釋含義明確，不要寫無意義的注釋和難以理解的詞匯

　　2.3命名規(guī)范

　　　　2.3.1包的命名：常用命名方式：com.公司名.產(chǎn)品線名.項(xiàng)目名.模塊名，所有名稱全部小寫

　　　　2.3.2類名和接口名的命名：盡量使用完整的英文描述，首字母大寫，每個(gè)英文單詞的首字母大寫，其余字母小寫。抽象類請以Abstract開頭，接口的實(shí)現(xiàn)類請以Impl接口，工具類請以Util或Utils結(jié)尾，如下列命名方式： StaffService、DefaultStaffService、AbstractEntity、StringUtils；

　　　　2.3.3、方法命名；盡量使用完整的英文描述，首字母小寫，每個(gè)英文單詞的首字母大寫，其余字母小寫，屬性存取盡量使用setX、getX，返回布爾類型值的方法盡量使用isX，如下列命名方式： queryStaffById、isCodeExists()、getValue

　　　　2.3.4、屬性命名；盡量使用完整的英文描述，首字母小寫，每個(gè)英文單詞的首字母大寫，其余字母小寫，屬性名和方法名不要重復(fù)；

　　　　2.3.5、常量命名；使用全部大寫的英文描述，每個(gè)單詞之間用下劃線分隔，變量之前近可能使用final修飾，注意：枚舉也是一種常量；

　　　　2.3.6、模塊內(nèi)部的組件，盡量以組件名開頭，如：StaffDAO、StaffService；

　　　　2.3.7、組件命名，盡量以組件類型結(jié)果，如：StaffService、OrgService；

　　　　2.3.8、準(zhǔn)確控制類成員方法的修飾符，如果僅限于類內(nèi)部使用用private修飾，可供子類或本包內(nèi)部使用用protected修飾，對所有公開，則用public；

　　　　2.3.9、屬性和方法的命名不易過長，一般不超過15個(gè)字母；

3?怎樣寫規(guī)范的代碼

　　　　包結(jié)構(gòu)清晰，類、接口、方法、屬性命名貼切易懂；

　　　　該注釋的地方注釋，注釋清楚、易懂，沒有二義性；

?　　　　接口定義明確，精確方法功能，每個(gè)方法只實(shí)現(xiàn)一個(gè)功能；

　　　　方法內(nèi)部的代碼行數(shù)控制在200行以內(nèi)，一個(gè)類的代碼行數(shù)控制在1000行以內(nèi)，如果你的類代碼在1000行以上，請重新思考設(shè)計(jì)思路，這里說的代碼行數(shù)不把注釋計(jì)算在內(nèi)；

　　　　多個(gè)方法內(nèi)部如果有相似的功能代碼塊，應(yīng)該提取為公用方法；

　　　　盡量將業(yè)務(wù)相近的方法放在一起，便于尋找；

　　　　方法內(nèi)部盡量不要catch異常，讓外部調(diào)用者知道出錯(cuò)細(xì)節(jié)；

　　　　方法內(nèi)部對于對象參數(shù)的調(diào)用，盡量判斷非null引用，除非你的設(shè)計(jì)能保證非空對象；

　　　　不用的數(shù)據(jù)及時(shí)是否，如果數(shù)據(jù)庫連接、集合、共享鎖等；

?

　　　　不要使用技巧性比較高的表達(dá)式；

對于方法拋出的自定義異常，應(yīng)該寫明異常描述信息；

評估你的數(shù)據(jù)，對變量采用合理的類型，如一個(gè)整數(shù)在1個(gè)字節(jié)8位以內(nèi)，應(yīng)該使用byte；

該用基本數(shù)據(jù)類型就用基本數(shù)據(jù)類型，明確告訴虛擬機(jī)你的數(shù)據(jù)類型，避免虛擬機(jī)幫你做類型轉(zhuǎn)換

紅色標(biāo)識 自己碰到過的需要改正的毛病

任重而道遠(yuǎn)！

附PSP

?

Job	Type	Data	Start	End	Total（min）
效能	編碼測試	3.13	14：30	15：20	50
效能隨筆	隨筆	3.14 3.15	14：20 10:40	14:51 10:50	41
了解燃盡、 甘特、魚刺圖	查閱	3.15	19：05	19:50	45
軟件對比分析	隨筆	3.16	13:50	14:35	45
小組工程需求討論	討論	3.16	17:50	19:50	120
代碼規(guī)范	查閱	3.16	21:05	21:30	25
總結(jié)隨筆	隨筆	3.16	22:30	23	?

工作量表

?

?	代碼行數(shù)	博客字?jǐn)?shù)	知識點(diǎn)
第二周	0	2500	代碼規(guī)范 工程控制 需求分析 效能分析

?

寫在最后

在這個(gè)課程中與“耐撕”一起完成搶答器項(xiàng)目，爭取在實(shí)踐中充分了解軟件工程的過程。加油！

?

轉(zhuǎn)載于:https://www.cnblogs.com/WeSure6/p/5285694.html

總結(jié)

以上是生活随笔為你收集整理的代码规范 任重而道远的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

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