1. 【強制】類、類屬性、類方法的注釋必須使用Javadoc規范,使用/\*\*內容\*/格式,不得使用
// xxx方式。
說明:在IDE編輯窗口中,Javadoc方式會提示相關注釋,生成Javadoc可以正確輸出相應注釋;在IDE中,工程調用方法時,不進入方法即可懸浮提示方法、參數、返回值的意義,提高閱讀效率。
1. 【強制】所有的抽象方法(包括接口中的方法)必須要用Javadoc注釋、除了返回值、參數、異常說明外,還必須指出該方法做什么事情,實現什么功能。說明:對子類的實現要求,或者調用注意事項,請一并說明。
2. 【強制】所有的類都必須添加創建者和創建日期。
3. 【強制】方法內部單行注釋,在被注釋語句上方另起一行,使用//注釋。方法內部多行注釋使用/\* \*/注釋,注意與代碼對齊。
4. 【強制】所有的枚舉類型字段必須要有注釋,說明每個數據項的用途。
5. 【推薦】與其“半吊子”英文來注釋,不如用中文注釋把問題說清楚。專有名詞與關鍵字保持英文原文即可。
反例:“TCP連接超時”解釋成“傳輸控制協議連接超時”,理解反而費腦筋。
1. 【推薦】代碼修改的同時,注釋也要進行相應的修改,尤其是參數、返回值、異常、核心邏輯等的修改。
說明:代碼與注釋更新不同步,就像路網與導航軟件更新不同步一樣,如果導航軟件嚴重滯后,就失去了導航的意義。
1. 【參考】謹慎注釋掉代碼。在上方詳細說明,而不是簡單的注釋掉。如果無用,則刪除。
說明:代碼被注釋掉有兩種可能性:1)后續會恢復此段代碼邏輯。2)永久不用。前者如果沒有備注信息,難以知曉注釋動機。后者建議直接刪掉(代碼倉庫保存了歷史代碼)。
1. 【參考】對于注釋的要求:第一、能夠準確反應設計思想和代碼邏輯;第二、能夠描述業務含義,使別的程序員能夠迅速了解到代碼背后的信息。完全沒有注釋的大段代碼對于閱讀者形同天書,注釋是給自己看的,即使隔很長時間,也能清晰理解當時的思路;注釋也是給繼任者看的,使其能夠快速接替自己的工作。
2. 【參考】好的命名、代碼結構是自解釋的,注釋力求精簡準確、表達到位。避免出現注釋的一個極端:過多過濫的注釋,代碼的邏輯一旦修改,修改注釋是相當大的負擔。
##### 反例:
// put elephant into fridge put(elephant, fridge);
方法名put,加上兩個有意義的變量名elephant和fridge,已經說明了這是在干什么,語義清晰的代碼不需要額外的注釋。
11\. 【參考】特殊注釋標記,請注明標記人與標記時間。注意及時處理這些標記,通過標記掃描,經常清理此類標記。線上故障有時候就是來源于這些標記處的代碼。
1) 待辦事宜(TODO):( 標記人,標記時間,\[預計處理時間\])
表示需要實現,但目前還未實現的功能。這實際上是一個Javadoc的標簽,目前的Javadoc 還沒有實現,但已經被廣泛使用。只能應用于類,接口和方法(因為它是一個Javadoc標簽)。
2) 錯誤,不能工作(FIXME):(標記人,標記時間,\[預計處理時間\])
在注釋中用FIXME標記某代碼是錯誤的,而且不能工作,需要及時糾正的情況。
- 一、編程規約????1
- (一) 命名風格????1
- (二) 常量定義????3
- (三) 代碼格式????4
- (四) OOP規約????6
- (五) 集合處理????9
- (六) 并發處理????12
- (七) 控制語句????14
- (八) 注釋規約????16
- (九) 其它????17
- 二、異常日志????18
- (一) 異常處理????18
- (二) 日志規約????19
- 三、單元測試????21
- 四、安全規約????23
- 五、MySQL數據庫????24
- (一) 建表規約????24
- (二) 索引規約????25
- (三) SQL語句????27
- (四) ORM映射????28
- 六、工程結構????30
- (一) 應用分層????30
- (二) 二方庫依賴????31
- (三) 服務器????32
- 附1:版本歷史????34
- 附2:本手冊專有名詞????35