Android 編碼規範，android編碼規範

Android 編碼規範，android編碼規範
一、命名規範1.1包命名

命名規則：一個唯一包名的首碼總是全部小寫ASCII字母並且是一個頂級網域名稱，通常是com,edu,gov,mil,net,org等。

規約：以公司為準，一般是com.公司名.項目名稱縮寫.模組名或層級名稱

1.2類和介面命名

命名規則：類名是一個名詞，採用大小寫混合的方式，每個單詞的首字母大寫。避免使用縮寫詞，除非該縮寫詞被更廣泛使用，如URL,HTML等。

                    介面命名，以大寫字母I開頭，每個單詞的首字母大寫。

1.3方法命名

命名規則：方法名是一個動詞，採用大小寫混合的方式，第一個單詞首字母小寫，其後所有單詞的首字母大寫

                   1.3.1 類的擷取方法（一般具有返回值）一般要求在被訪問的欄位名前加上get。一般來說，get首碼方法返回的是單個值，find方法返回的是列表值。

                   1.3.2類的設定方法（一般返回值為void）被訪問欄位名前面加上set

                   1.3.3類的布爾型的判斷方法一般要求方法名使用單詞is或has做首碼，或者使用具有邏輯意義的單詞，例如equal或equals。

                   1.3.4類的普通方法一般採用完整的英文描述說明成員方法功能，第一個單詞儘可能採用動詞，首字母小寫

                   1.3.5構造方法應該用遞增的方式寫即參數多的寫在後面。

1.4變數命名

命名規則：第一個單詞的首字母小寫，其後單詞的首字母大寫。變數名不應以底線或貨幣符號開頭，儘管這在文法上是允許的。盡量避免單個字元的變數名，除非是一次性的臨時變數。臨時變數通常被取名為 i，j，k，m 和 n，它們一般用於整型；c，d，e，它們一般用於字元型。變數命名不允許出現無意義的單詞。

1.5成員變數命名

同變數命名，但要在成員變數前添加m字樣，後面字母以大寫開頭，比如mEditHours。

靜態變數前添加s字樣，後面字母以大寫開頭，比如sEditTime。

1.6常量命名

命名規則：類常量的聲明，應該全部大寫，單詞間用底線隔開。

1.7異常命名

規則：自訂異常的命名必須以Exception為結尾。以明確標示為一個異常。

1.8Layout命名

規約：layout xml的命名必須以全部單詞小寫，單詞間以底線分割，並且使用名詞或名詞片語，即使用模組名_功能名稱來命名。

1.9 ID命名

規約：layout中所使用的id必須以全部單詞小寫，單詞間以底線分割，並且使用名詞或名詞片語，並且要求能夠通過id直接理解當前組件要實現的功能。

1.10資源命名

規約：layout中所使用的所有資源（如drawable,style等）命名必須以全部單詞小寫，單詞間以底線分割，並且儘可能的使用名詞或名片語，即使用模組名_用途來命名。如果為公用資源，如分割線等，則直接用用途來命名。

二、注釋規範

釋與代碼的比例要求為30%，注釋語言必須準確、易懂、簡潔。

Java程式有兩類注釋：實現注釋(implementationcomments)和文檔注釋(document comments)。實現注釋是使用/*...*/和//界定的注釋。文檔注釋(被稱為"doc comments")由/**...*/界定。文檔注釋可以通過javadoc工具轉換成HTML檔案。

2.1 檔案注釋

源檔案頭部應進行注釋，列出：著作權說明、版本號碼、模組目的/功能、作者、產生日期、修改日誌等。

檔案頭模板：

/**  

 * @Title: ${file_name}

 * @Package: ${package_name}

 * @Description: ${todo}(用一句話描述該檔案做什麼)

 * Copyright: 

 * Company: 

 *

 * @author ${user}

 * @date ${date} ${time}

 * @version V1.0

 */

說明：檔案描述一項描述本檔案的內容、功能、內部各部分之間的關係及本檔案與其它檔案關係等。2.2類注釋

每一個類都要包含如下格式的注釋，以說明當前類的功能等。

/**

 * @ClassName: ${type_name}

 * @Description: ${todo}(這裡用一句話描述這個類的作用)

 * @author ${user}

 * @date ${date} ${time}

 *

 * ${tags}

 */

2.3方法注釋

每一個public方法都要包含如下格式的注釋，包括當前方法的用途，當前方法參數的含義，當前方法返回值的內容和拋出異常的列表。

/**

 * @Title: ${enclosing_method}

 * @Description: ${todo}(這裡用一句話描述這個方法的作用)

 * @param: ${tags} 參數名稱

 * @return: ${return_type} 傳回型別

 * @throws

 */

2.4類成員和變數注釋

成員變數和常量需要使用java doc形式的注釋，以說明當前變數或常量的含義。

/**

 * @Fields ${field}: ${todo}(用一句話描述這個變數表示什麼)

 */2.5代碼注釋

        2.5.1修改代碼時應修改相應的注釋

        2.5.2注釋應與其描述的代碼相近，不可放在下面，如放於上方則需與其上面的代碼用空行隔開。

        2.5.3對資料結構的注釋應放在其上方相鄰位置，不可放在下面；對結構中的每個域的注釋放在此域的右方。

        2.5.4協助讀者理解代碼，防止沒必要的重複注釋資訊。

        2.5.5.當程式碼片段較長，特別是多重嵌套時，注釋可以使代碼更清晰，更便於閱讀。

2.6修改已有類的注釋

修改已有類時需要添加歷程記錄，如下，空一行後添加歷程記錄、修改內容、Review記錄三行。

2.7修改代碼注釋

2.8XML注釋

規約：如果當前layout 或資源需要被多處調用，或為公用使用的layout（若list_item），則需要在xml寫明注釋。要求注釋清晰易懂。

2.9Code Review注釋

2.10其他注釋

方法內部的注釋如果需要多行使用/*…… */形式，如果為單行是用//……形式的注釋。不要再方法內部使用 java doc 形式的注釋“/**……**/”，簡單的區分方法是，java doc形式的注釋在 eclipse中為藍色，普通注釋為綠色。

三、代碼風格3.1縮排

規約：不允許使用Tab進行縮排，使用空格進行縮排，推薦縮排為4空格。

3.2空行

下列情況應該總是使用空行：

1、一個源檔案的兩個片段(section)之間

2、類聲明和介面聲明之間

3、兩個方法之間

4、方法內的局部變數和方法的第一條語句之間

5、一個方法內的兩個邏輯段之間，用以提高可讀性 

規約：通常在變數聲明地區之後要用空行分隔，常量聲明地區之後要有空行分隔，方法聲明之前要有空行分隔。3.3行寬

無特別規定，因為現在的顯示器都比較大，所以推薦使用120進行設定。

四、規範約定

4.1方法

一個方法盡量不要超過15行，如果方法太長，說明當前方法商務邏輯已經非常複雜，那麼就需要進行方法拆分，保證每個方法只作一件事。

4.2參數與返回值

一個方法的參數儘可能的不要超過4個。

儘可能不要使用null，替代為異常或者使用空變數如返回 List 則可以使用Collections.emptyList()。

4.3幽靈數字（參數與返回值）

代碼中不允許出現單獨的數字，字元！如果需要使用數字或字元，則將它們按照含義封裝為靜態常量！（for語句中除外）

4.4控制語句

判斷中如有常量，則應將常量置於判斷式的右側。

盡量不使用三目條件的嵌套。

所有if 語句必須用{}包括起來，即便是只有一句。

4.5異常捕獲

若有finally 子句，則不要在try 塊中直接返回，亦不要在finally 中直接返回。

4.6存取控制五、約定俗成5.1變數賦值

避免在一個語句中給多個變數賦相同的值。

不要將賦值運算子用在容易與相等關係運算子混淆的地方。

不要使用內嵌(embedded)賦值運算子試圖提高運行時的效率，這是編譯器的工作。

5.2圓括弧5.3返回值

設法讓你的程式結構符合目的。

5.4二元運算式

如果一個包含二元運算子的運算式出現在三元運算子" ? : "的"?"之前，那麼應該給運算式添上一對圓括弧。

六、21種代碼壞味道

1.Duplicated Code  重複代碼

2.Long Method  過長函數

3.Large Class   過大的類

4.Divergent Change   發散式變化

5.Shotgun Surgery     散彈式修改

6.Feature Envy   依賴情結

7.Data Clumps  資料泥團

8.Primitive Obsession    基本類型偏執

9.Switch Statement    多分支選擇語句

10.Parallel Inheritance Hierarchies   平行繼承體系

11.Lazy Class   冗贅類

12.Speculative Generality  夸夸其談未來性

13.Temporary Field 令人迷惑的暫時值域

14.Message Chain  過度耦合的訊息鏈

15.Middle Man  中間轉手人

16.Inappropriate Intimacy   狎昵關係

17.Alternative Classes with Different Interfaces 異曲同工的類

18.Incomplete Library Class  不完善的程式類庫

19.Data Class   純粹的資料類

20.Refused Bequest   被拒絕的遺贈

21.Comments   過多的注釋

按照Android代碼規範，類中的私人成員變數前必須加m？

這玩意，根據每個人習慣不同，並沒有一定的標準。
我一般這樣，私人的或者被保護的成員變數，還有方法全部用_開頭，不加類型首碼，而用含義字串來命名。
比如兩個TextView 一個是標題，一個是使用者名稱
private TextView _title;
private TextView _userName;
一個方法擷取使用者名稱
private String _getUserName();

前面加類型首碼的那種匈牙利標記法，對java這種環境不太適合，java開發，首碼區分類型根本不必要，區分含義才比較重要。

共有或者包許可權的就不加_,
public String dummy;
public String getCurrentUser();

這樣好看不說，而且寫出來的東西，知道是什麼含義，注釋都省了。
 
android 的系統包命名規範問題

一般都是，com.公司名.包名，我所在的公司，雖然不大，但那些老工程師都是這樣的，盡量讓人看你名字就知道，少看注釋。