Android 編碼規範

1、命名規範

1.1包命名

命名規則:一個惟一包名的前綴老是全部小寫ASCII字母並且是一個頂級域名,通常是com,edu,gov,mil,net,org等。java

規約:以公司爲準。一般是com.公司名.項目名稱縮寫.模塊名或層級名稱session

1.2類和接口命名

命名規則:類名是一個名詞。採用大寫和小寫混合的方式。每個單詞的首字母大寫。避免使用縮寫詞。除非該縮寫詞被更普遍使用,如URL,HTML等。數據結構

                    接口命名,以大寫字母I開頭。每個單詞的首字母大寫。app

1.3方法命名

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

                   1.3.1 類的獲取方法(通常具備返回值)通常要求在被訪問的字段名前加上get。函數

通常來講,get前綴方法返回的是單個值。find方法返回的是列表值。工具

                   1.3.2類的設置方法(通常返回值爲void)被訪問字段名前面加上setpost

                   1.3.3類的布爾型的推斷方法通常要求方法名使用單詞is或has作前綴,或者使用具備邏輯意義的單詞,好比equal或equals。日誌

                   1.3.4類的普通方法通常採用完整的英文描寫敘述說明成員方法功能,第一個單詞儘量採用動詞。首字母小寫xml

                   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等)命名必須以全部單詞小寫。單詞間下面劃線切割,並且儘量的使用名詞或名詞組,即便用模塊名_用途來命名。假設爲公共資源。如切割線等,則直接用用途來命名。

2、凝視規範

釋與代碼的比例要求爲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、代碼風格

3.1縮進

規約:不一樣意使用Tab進行縮進。使用空格進行縮進。推薦縮進爲4空格。

3.2空行

下列狀況應該老是使用空行:

一、一個源文件的兩個片斷(section)之間

二、類聲明和接口聲明之間

三、兩個方法之間

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

五、一個方法內的兩個邏輯段之間,用以提升可讀性 

規約:一般在變量聲明區域以後要用空行分隔。常量聲明區域以後要有空行分隔。方法聲明以前要有空行分隔。

3.3行寬

無特別規定,因爲現在的顯示器都比較大,因此推薦使用120進行設置。

4、規範約定

4.1方法

一個方法儘可能不要超過15行,假設方法太長,說明當前方法業務邏輯已經很複雜,那麼就需要進行方法拆分,保證每個方法僅僅做一件事。

4.2參數與返回值

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


儘量不要使用null,替代爲異常或者使用空變量如返回 List 則可以使用Collections.emptyList()。

4.3幽靈數字(參數與返回值)

代碼中不一樣意出現單獨的數字。字符!假設需要使用數字或字符。則將它們依照含義封裝爲靜態常量!(for語句中除外)

4.4控制語句

推斷中若有常量,則應將常量置於推斷式的右側。

儘可能不使用三目條件的嵌套。

所有if 語句必須用{}包含起來,即使是僅僅有一句。

4.5異常捕獲

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

4.6訪問控制

5、約定俗成

5.1變量賦值

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

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

不要使用內嵌(embedded)賦值運算符試圖提升執行時的效率,這是編譯器的工做。

5.2圓括號

5.3返回值

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

5.4二元表達式

假設一個包括二元運算符的表達式出現在三元運算符" ? : "的"?

"以前。那麼應該給表達式添上一對圓括號。

6、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   過多的凝視

相關文章
相關標籤/搜索