Android 編碼規範

標籤：之間   imp   拋出異常   tracking   調用   list   基本   縮排   doc   

一、命名規範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變數賦值

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

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

不要使用內嵌(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 編碼規範