【強制】類、類屬性、類方法的注釋必須使用 Javadoc 規范，使用/**內容*/格式，不得使用

// xxx 方式。

說明：在 IDE 編輯窗口中，Javadoc 方式會提示相關注釋，生成 Javadoc 可以正確輸出相應注釋；在 IDE

中，工程調用方法時，不進入方法即可懸浮提示方法、參數、返回值的意義，提高閱讀效率。

?

【強制】所有的抽象方法（包括接口中的方法）必須要用 Javadoc 注釋、除了返回值、參數、

異常說明外，還必須指出該方法做什么事情，實現什么功能。

說明：對子類的實現要求，或者調用注意事項，請一并說明。

?

【強制】所有的類都必須添加創建者和創建日期。

?

【強制】方法內部單行注釋，在被注釋語句上方另起一行，使用//注釋。方法內部多行注釋

使用/* */注釋，注意與代碼對齊。

?

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

?

【推薦】與其“半吊子”英文來注釋，不如用中文注釋把問題說清楚。專有名詞與關鍵字保

持英文原文即可。

反例：“TCP 連接超時”解釋成“傳輸控制協議連接超時”，理解反而費腦筋。

?

【推薦】代碼修改的同時，注釋也要進行相應的修改，尤其是參數、返回值、異常、核心邏

輯等的修改。

說明：代碼與注釋更新不同步，就像路網與導航軟件更新不同步一樣，如果導航軟件嚴重滯后，就失去了

導航的意義。

?

【參考】謹慎注釋掉代碼。在上方詳細說明，而不是簡單地注釋掉。如果無用，則刪除。

說明：代碼被注釋掉有兩種可能性：1）后續會恢復此段代碼邏輯。2）永久不用。前者如果沒有備注信

息，難以知曉注釋動機。后者建議直接刪掉（代碼倉庫已然保存了歷史代碼）。

?

【參考】對于注釋的要求：第一、能夠準確反映設計思想和代碼邏輯；第二、能夠描述業務

含義，使別的程序員能夠迅速了解到代碼背后的信息。完全沒有注釋的大段代碼對于閱讀者

形同天書，注釋是給自己看的，即使隔很長時間，也能清晰理解當時的思路；注釋也是給繼

任者看的，使其能夠快速接替自己的工作。

?

【參考】好的命名、代碼結構是自解釋的，注釋力求精簡準確、表達到位。避免出現注釋的

一個極端：過多過濫的注釋，代碼的邏輯一旦修改，修改注釋是相當大的負擔。

反例：

// put elephant into fridge

put(elephant, fridge);

方法名 put，加上兩個有意義的變量名 elephant 和 fridge，已經說明了這是在干什么，語義清晰的代

碼不需要額外的注釋。

總結

以上是生活随笔為你收集整理的阿里Java编程规约（注释）提炼的全部內容，希望文章能夠幫你解決所遇到的問題。

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