1 代碼規范化的意義

　　1.1軟件維護是軟件生命周期中持續時間最長的階段。因此代碼總會被很多人去維護，規范的代碼可以減少維護人員的理解時間，降低維護代價，方便進行二次開發

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

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

　　1.4建議性的規范幫助編碼人員寫出易理解、易維護、易擴展的優秀代碼

2 編碼規范指南

　　2.1排版規范

　　　　2.1.1程序塊采用縮進，縮進空位為4個

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

　　　　2.1.3較長的語句、表達式、參數要書寫多行

　　　　2.1.4一行只寫一條語句

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

　　　　2.1.6相對獨立的業務語句塊之間，變量說明后加空行

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

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

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

　　2.2注釋規范

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

　　　　2.2.2包的注釋：在包的當前路徑放入一名為package.html的HTML文件，方面JavaDoc收集。注釋內容簡述本包的作用、內容、產品模塊、版本、版權等

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

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

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

　　　　2.2.6類方法注釋需要記載方法的功能簡述、詳細、輸入參數、輸出值、拋出的異常、作者等

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

　　2.3命名規范

　　　　2.3.1包的命名：常用命名方式：com.公司名.產品線名.項目名.模塊名，所有名稱全部小寫

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

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

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

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

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

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

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

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

3?怎樣寫規范的代碼

　　　　包結構清晰，類、接口、方法、屬性命名貼切易懂；

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

?　　　　接口定義明確，精確方法功能，每個方法只實現一個功能；

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

　　　　多個方法內部如果有相似的功能代碼塊，應該提取為公用方法；

　　　　盡量將業務相近的方法放在一起，便于尋找；

　　　　方法內部盡量不要catch異常，讓外部調用者知道出錯細節；

　　　　方法內部對于對象參數的調用，盡量判斷非null引用，除非你的設計能保證非空對象；

　　　　不用的數據及時是否，如果數據庫連接、集合、共享鎖等；

?

　　　　不要使用技巧性比較高的表達式；

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

評估你的數據，對變量采用合理的類型，如一個整數在1個字節8位以內，應該使用byte；

該用基本數據類型就用基本數據類型，明確告訴虛擬機你的數據類型，避免虛擬機幫你做類型轉換

紅色標識 自己碰到過的需要改正的毛病

任重而道遠！

附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
代碼規范	查閱	3.16	21:05	21:30	25
總結隨筆	隨筆	3.16	22:30	23	?

工作量表

?

?	代碼行數	博客字數	知識點
第二周	0	2500	代碼規范 工程控制 需求分析 效能分析

?

寫在最后

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

?

轉載于:https://www.cnblogs.com/WeSure6/p/5285694.html

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。