Android注釋實例分析

這篇文章主要講解了“Android注釋實例分析”，文中的講解內容簡單清晰，易于學習與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學習“Android注釋實例分析”吧！

曾經的我被批評過很多次寫的注釋寫的很糟糕，我原本以為把函數名取得長一點，意思更明確一些，變量更易懂一些，就不用寫注釋了。結果后來我去年的代碼給評獎的時候，說注釋不規范，每個函數就幾行，看不懂。有一次同事問我新增代碼多少，我看了一下代碼統計，發現不多，但是突然注意到注釋率56%。也就是說100行代碼，有56行注釋。真是神一樣的代碼。 這次我倒是真的“專心”寫了注釋的。每一個函數頭都謝了注釋，即便是構造函數，也寫了注釋。

/*******************************************
* 作用：構造函數* 輸入：無
*輸出：無
*作者：xxxxxxxxxxx
********************************************/
XXXXXXXXX:XXXXXXXX()
{
}

這樣，兩行代碼，寫了6行注釋，會得到很高的注釋率。但，這個注釋，真的有用么？ 神一樣的注釋還有：

/**********************************************
Function name:*
Param:*
IN:*
OUT:*
Reference by:*
Called by:*
Return:
History:*
Author:*
Date:*
*********************************************/

剛進公司的時候，發的是一個17寸的LCD，一個代碼要滾很多屏幕才能滾完。這些注釋都是Source Insight的一個插件搞得，相當霸道。但很多注釋完全是為了注釋而注釋，一個有用信息都沒有。每次看到這種注釋都有種沖動想把它干掉。前段時間新員工代碼檢視被軟件部經理說注釋不齊全，說這些要補齊。幸好當時我看到了，她正在機械的補齊Reference by這些注釋。我立刻制止，給她一份我的注釋

/******************************************
功能：
參數：
返回值：
作者：
******************************************/

并且，如果沒有的信息，不要填。如果返回值是void，這一行就干掉。 我認為注釋真的要寫一些有意義的東東，寫一些不容易變化的，重要的。例如什么函數名寫來干啥，下面不是立刻就有？構造函數和析構，如果不是帶參數的，也建議不寫。誰不知道這是個構造函數？ 還有一種特色的注釋，如果你打開華為的G330手機的ROM的build.prop文件，你就會看到這種神奇的注釋：

persist.fuse_sdcard=false
#DTS2012011902027 guanjunujie 20120120 begin
ro.config.hw_allowformat=true
#DTS2012011902027 guanjunujie 20120120 end
#DTS2012011902069 guanjunujie 20120120 begin
ro.config.hw_allow_ums_and_mtp=true
#DTS2012011902069 guanjunujie 20120120 end
#DTS2012021607935 guanjunujie 20120214 begin
ro.config.switchPrimaryVolume=true
#DTS2012021607935 guanjunujie 20120214 end
# DTS2012022802590 wuye00193878 20120229 begin
ro.config.internal_sdcard=yes
ro.config.hw_cdma_cdg=false
# DTS2012022802590 wuye00193878 20120229 end
#/*< DTS2012031303262 yufei 20120313 begin */
#/*< DTS2012022306777 yufei 20120301 begin */ #/*DTS2012022306777 yufei 20120301 end >*/
#/*DTS2012031303262 yufei 20120313 end >*/
# /* # /* # /* */
# /* DTS2012030302649 tiandazhang 20120303 end> */
# /* DTS2012031100199 tiandazhang 20120311 end> */
#DTS2012030300592 Cheng Wei c81003953 2012-03-09 add begin.
ro.build.characteristics=default
#DTS2012030300592 Cheng Wei c81003953 2012-03-09 add end.
#DTS2012022804910 chensaitao 20120323 begin
ro.config.hw_test_version=false
#DTS2012022804910 chensaitao 20120323 end
# DTS2012062806152 z81003396 20120628 Delete ro.huawei.cust.drm.fl_only=true.
#/**/
# DTS2012032607960 tiandazhang 20120327 begin
ro.config.widevine_level3=true
# DTS2012032607960 tiandazhang 20120327 end
#/**/

# DTS2012041703860 zhangqijia 20120417 begin
# DTS2012080800950 baitao 20120905 begin
ro.com.google.gmsversion=ics_signed_r4
# DTS2012080800950 baitao 20120905 end
# DTS2012041703860 zhangqijia 20120417 end

#DTS2012022002232 wangwenbo 20120220 begin
ro.config.hwft_simrefresh=true
#DTS2012022002232 wangwenbo 20120220 end

我在當時移植4.1的時候，就被這些“注釋”搞得頭暈眼花。不覺得這些都是些天書么？他們試圖想代替版本管理軟件，來展現一段歷史。

在我們的一些老代碼中，也有很多類似的注釋，一連幾個begin，然后不知道哪里end，然后一行代碼被圍上了好幾個begin。看代碼的人不斷滾屏。我當新員工的時候就問，為啥要這么搞？憑啥要這么搞？被告知，和代碼的時候要方便點。

后來，當我真正用到IBM的Clearcase的時候，我才知道，為啥這樣要“方便一點”。Clearcase，至少在7.x版本，還是沒有一個元commit的概念。他只能每個文件生成一個節點，對每次commit，都會給不同的文件形成多個節點。每次commit，其實是對幾個文件的commit，之間沒有絲毫的關系。所以一旦上庫后，你想知道某個問題是怎么修改的，你光看一個文件，沒法找到其他文件的修改！而SVN，GIT這些，每次commit都是一個完整的集合，則不存在這些問題。所以，在這樣老土的版本管理軟件下，只能采取類似的注釋，企圖能夠快點找到所有的修改。特別是CMO合并問題單的時候！

但這樣，真的是相當的不安全。所以我采取的做法是，我在問題單中貼上我所有的修改，但不在代碼中做注釋，你想合并問題，自己看我的問題單，理解了，然后再合并。省得由于我的begin end沒有整對，到時候怪到我頭上。

感謝各位的閱讀，以上就是“Android注釋實例分析”的內容了，經過本文的學習后，相信大家對Android注釋實例分析這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是億速云，小編將為大家推送更多相關知識點的文章，歡迎關注！