Android編程規范
命名規范
-
基本原則
(1) 代碼風格與android源碼保持一致
(2) 命名要清晰明了、有明確含義
(3) 同一產品命名風格要保持一致,避免一意多詞
(4) 同一作用域,不能有變量重名,如局部變量與全局變量重名
-
包名
(1) package命名如com.brian.xx.yy.zz,xx為產品,yy為模塊,zz為子模塊
(2) 模塊劃分,按以下兩種方式均可,但需要項目組統一
- 按產品業務劃分,如
com.brian.example.homepage 和 com.brian.example.player - 按邏輯功能劃分,如
com.brian.example.homepage.ui 和 com.brian.example.homepage.logic
</ul> </li>
-
類成員命名,參考android源碼,如 android.content.pm.PackageManager
(1) 類: public abstract class PackageManager
(2) 函數: public abstract PackageInfogetPackageInfo(String packageName)
(3) 常量: public static final int GET_ACTIVITIES= 0x00000001;
(4) 靜態變量: static ComponentName sComponent;
(5) 成員變量: ComponentName mComponent;
(6) 臨時變量: ComponentName component; -
對于簡單的內部類,或則DTO(數據傳輸對象),成員變量名稱可以不帶前綴m
public final class Message implements Parcelable { /**
- User-defined message code so that the recipient can identify
- what this message is about. Each {@link Handler} has its own name-space
- for message codes, so you do not need to worry about yours conflicting
- with other handlers. */ public int what;
/**
- arg1 and arg2 are lower-cost alternatives to using
- {@link #setData(Bundle) setData()} if you only need to store a
- few integer values. */ public int arg1;
/**
- arg1 and arg2 are lower-cost alternatives to using
- {@link #setData(Bundle) setData()} if you only need to store a
- few integer values. */ public int arg2; }</code></pre> </li>
-
接口命名,參考android源碼,如android.view.View.OnClickListener
/**
- Interface definition for a callback to be invoked when a view is clicked.
*/
public interface OnClickListener {
/**
- Called when a view has been clicked. *
- @param v The view that was clicked.
/
void onClick(View v);
}</code></pre> </li>
資源命名
(1) 文件名(字母小寫和下劃線組成)
- activity_main.xml
- ic_launcher.png </ul>
- android:id="@+layout/loading_view"
- <string name="app_name">應用名稱</string>
-
文字編碼
(1) 統一使用utf8編碼
-
縮進對齊
(1) 代碼縮進采用 4個空格
(2) 代碼行首,合理縮進,以簡潔明了為原則
-
空格
(1) 條件語句,關鍵字與“(”用空格隔開,如 if (xx)、while (i> 3)
(2) 注釋內容,左右用空格隔開,如 // xxx,/ xxx /
(3) 比較操作符、賦值操作符、算術操作符、邏輯操作符、位操作符,等雙目操作符的前后加空格
if ( (a >= b) && (c <= d) ) if (size >= MAX_SIZE) a = b + c; a
(2) 資源名id(字母小寫和下劃線組成)
代碼排版
(4) "!"、"~"、"++"、"--"、"&"(地址運算符)等單目操作符前后不加空格
*p = 'a'; flag = !isEmpty; p = &mem; i++;
(5) 逗號、分號(非行結束符號)在后面加空格,前面不加空格
int x = 1, y = 2, z = 3; function(x, y, z); for (inti = 0; i < 10; i++)
-
條件語句(if、for、while、do)
(1) 條件語句,使用完備的括號
if (a == b && c == d) // BAD if ((a == b) && (c == d))// GOOD
(2) 條件語句,獨自占一行,執行語句不得緊跟其他
// BAD if (flag) doSomething();
// GOOD if (flag){ doSomething(); }</code></pre>
(3) 條件語句,不論語執行句有多少行都要加“{}”
// BAD for (inti = 0; i < 10; i++) doSomething();
// GOOD for (inti = 0; i < 10; i++){ doSomething(); }</code></pre> </li>
代碼結構
(1) 一行只寫一條語句
// BAD x = a + b; y = c + d; z = e + f;
// GOOD x = a + b; y = c + d; z = e + f;</code></pre>
(2) 代碼以“段”來編寫,作用相近的代碼寫在一段,段與段間以空行分開,注釋也相應以“段”來注釋,如
public void filterData(Data in, Data out) {
// 預處理 clip(in.a + 100); clip(in.b + 200); clip(in.c + 300);
// 濾波 intavg = (in.a + in.b + in.c) / 3; int tmp1 = in.a + avg; int tmp2 = in.b - avg; int tmp3 = in.c + tmp1 + tmp2;
// 保存結果 out.a = tmp1; out.b = tmp2; out.c = tmp3; }</code></pre>
(3) 代碼文件中從上到下,函數依次按照調度、被調度的順序出現,例如
public void funA() { funB(); ... }
public void funB() { ... }</code></pre> </li> </ol>
代碼注釋
-
基本原則
(1) 注釋語言必須準確、簡潔、易懂,能直接反映編程思路
(2) 統一使用中文作為注釋語言,除非直接拷貝第三方的英語注釋
(3) 注釋比例沒有嚴格的要求,建議不低于15%
(4) 注釋要與代碼保持一致,代碼作用變了,注釋也要更新
(5) 對于邏輯復雜、使用有限制的代碼,需要重點注釋
-
必須注釋
(1) 文件
(2) 類
(3) 函數(對外接口public函數)
(4) 常量
(5) 成員變量(有特殊含義)
(6) 靜態變量
(7) 特殊邏輯、定制邏輯、有坑邏輯、臨時邏輯
-
建議注釋
(1) 復雜的邏輯
(2) 重要的分支,如 if-else,switch-case
(3) 重要的循環,說明,“每次循環遍歷…”
-
注釋樣式
(1) 注釋樣式參考android源碼
(2) 代碼以“段”來編寫,注釋也相應以“段”來注釋
/**
- 函數注釋 */ public void foo() { }
/**
- 函數注釋
- @param a
- @param b
- @return */ public int math(int a, int b) { }
/**
- 成員變量注釋 */ public int mValue;
// 一段代碼注釋 xxx xxx xxx
xxx xxx // 一行代碼注釋 xxx
// if分支注釋(1) if (true) { } // else分支注釋(1) else { }
if (true) { // if分支注釋(2) } else { // else分支注釋(2) }
// switch注釋 switch (xxx) { // case注釋(1) case xxx : break; case xxx : // case注釋(2) break; default: break; }</code></pre> </li> </ol>
模塊設計
-
基本原則
(1) 開放封閉
(2) 單一職責
(3) 倒置依賴
(4) 高內聚低耦合
-
分層設計
原則上,程序實現業務功能時,按MVC模式,從上至下進行分層設計
(1) 應用層:負責UI展示、下發操作指令
(2) 服務層:負責控制邏輯、數據維護
(3) 數據層:負責底層數據獲取,包括網絡、數據庫、文件、底層算法
-
模塊交互
(1) 原則上,下層功能代碼不能import上層業務的package,如下層操作數據庫的類不能import上層UI的activity
(2) 上層模塊調度下層模塊,通過下層public接口函數
(3) 下層模塊回調上層模塊,通過interface執行回調(不用handler)
(4) 廣播或則單播監聽事件,同時具有attach和detach操作
(5) 非特殊情況,調度與回調默認在UI線程執行
(6) 非特殊情況,獲取對象的變量統一使用getter、setter操作
-
代碼分離
(1) 分開:界面代碼、數據代碼
(2) 分開:業務相關代碼、底層通用模塊代碼
(3) 分開:基本模塊、特殊定制模塊
函數設計
-
基本原則
(1) 一個函數只做一件事
(2) 按抽象層劃分函數
(3) 向下調度原則
(4) 高扇入低扇出
-
其他建議
(1) 代碼以“段”編寫,合理分隔不相關的代碼段
(2) 禁止代碼中實現與函數名不相關的邏輯
(3) 禁止代碼中出現魔鬼數字
(4) 避免多處出現雷同的代碼,應提取公共的功能函數,或則調整調度入口
(5) 避免嵌套邏輯太深,超過3~5層,建議優化
(6) 避免復雜的復合判斷條件,建議分拆
(7) 避免山寨臨時邏輯
(8) 函數的參數超過5個,則使用參數對象封裝參數,有助于擴展接口
(9) 降低臨時變量的生命周期
(10)廢棄的代碼及時清理
其他參考
-
《Android Code Style》
https://source.android.com/source/code-style.html -
《Java Programming Style Guidelines》
http://geosoft.no/development/javastyle.html -
《Google Java Style》
https://google.github.io/styleguide/javaguide.html
來自:http://www.jianshu.com/p/e4229061fceb
- 按產品業務劃分,如