無規矩不成方圓,尤其是在團隊開發中,沒有規範的程式碼風格各異,既不利於程式碼的閱讀和維護,也會降低整個團度的開發效率,降低程式碼的質量。關於android的編碼規範,其實規則都已經比較成熟,這裡總結一下我的開發經歷,作為專欄的一個開頭!
命名規範
包命名及分包結構規範
- 包名沿用Java程式設計的通用風格
類命名規範
基本的類名沿用Java程式設計的通用風格(採用完整的英文描述符,所有單詞第一個字母大寫,採用駝峰式命名)
android特有的類,如Activity、Fragment、Service、Provider、Adapter、View等,則以對應的型別單詞為字尾
介面命名規範
類命名以大寫字母I為字首,如果是監聽介面以Listener結尾
在自定義的監聽介面裡,監聽事件以on開頭,如onOpenMenu(), onRefresh()...
方法命名規範
- 方法命名沿用Java程式設計的通用風格(採用完整的英文描述符,函式名字以代表函式功能的英文單片語成,除首單詞小寫,其他單詞首字母大寫;一般的,函式第一個單詞要求用動詞)
變數命名規範
boolean成員要以is開頭,或以has開頭。如: isFirst, hasMore
控制元件命名規範: 原則是“view的縮寫 + 功能描述”。 比如一個TextView縮寫為tv(駝峰命名抽取出來的縮寫), 這個TextView是顯示使用者名稱字的, 所以就可以命名為: tvUserName。
常量的名字全部大寫,單詞之間用’_’分開
控制元件命名規範: 原則是“view的縮寫 + 功能描述”。 比如一個TextView縮寫為tv(駝峰命名抽取出來的縮寫), 這個TextView是顯示使用者名稱字的, 所以就可以命名為:tvUserName
TextView : tv | EditText : et | Button : btn | ImageButton : ib |
---|---|---|---|
ImageView : iv | CheckBox : cb | RadioButton : rb | ProgressBar : pb |
Seekbar : sb | ScrollView : sv | ListView : lv | GridView : gv |
WebView : wv | ViewPager : vp | ExpandableListView : elv |
格式規範
註釋規範
檔案頭註釋(檔案要加檔案頭)
/** * @author xxxx * @date xxxx年xx月xx日 * Copyright xxxx. All rights reserved. */複製程式碼
類/介面註釋(必須註明類/介面的編寫目的、用途)
/** * 類或介面的作用描述 * @author XXX<email> * @version xxxx-xx-xx(xxxx-xx-xx為年月日) * Copyright XXXX. All rights reserved. */複製程式碼
方法頭註釋
/** * 方法的描述 * @param 引數的描述 * @return 返回型別的描述 * @exception 異常資訊的描述 */複製程式碼
方法體註釋
使用"//"進行註釋,註釋的內容包括:
- 控制流結構說明
- 變數說明
- 複雜程式碼說明
- 處理順序說明
空行使用規範
package和import之間要空一行
給不同功能的程式碼塊之間加上空行, 提升可讀性
括弧使用規範
括號沿用Java風格,即左弧號{是在方法宣告這一行,而不是C++式的另起一行
即使只有一行內容, if/else/for/while等條件或迴圈,都要加上大括號{ }
程式碼位置放置規範
Activity以onCreate()作為第一個方法, 其它類以建構函式做為第一個方法。 提高可讀性
功能上相近,有呼叫關係的函式儘量緊挨在一起
Activity、Fragment這些android裡面具備生命週期的類,儘量把生命週期的方法按順序排到一起,提高可讀性
內部類/介面建議統一放在檔案的開頭或者結尾
優化
儘量不要有重複程式碼。 一發現有重複程式碼,就要進行重構,抽取出一個公有類/方法
有大量if/else時,考慮下有無可能用策略模式、模板方法模式、面向介面程式設計來消除這種大量的if/else
一個JavaBean類, 比如就是存一些資料的一個Response類,如果是要開放一個成員給別人用, 這個成員又有getter,又有setter, 那就直接宣告為public。
layout檔案中, 層數不要過多, 儘量控制在6層以內。 當然,層數越少越好。
對於一個佈局檔案中的控制元件具備大量相同的屬性的時候,考慮將這些共同屬性提取稱為style進行使用
寫佈局檔案需要觀察佈局的效果的時候,使用tools:xxx,不要直接使用android:xxx
對於activity中常用的自己定義的initView、initData這些方法抽象出來放到對應的基類當中
在設計某些功能、邏輯複雜的類或模組的時候,建議另外寫一份設計文件,方便後人理解。
適配
- 長寬用dp做單位, 一般不推薦用px。 如果有特殊理由, 可以用px。 比如UED同學要求一條分隔線就只有1px寬
接下來自己會堅持寫專欄,既是對自己學到的東西的總結, 也是跟大家一起分享學習。歡迎大家關注。我的個人主頁是淺唱android,我的文章也會在上面釋出。謝謝大家寶貴的時間!