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變量賦值
避免在一個語句中給多個變量賦同樣的值。
不要將賦值運算符用在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 編碼規範