android 編碼規範

無規矩不成方圓，尤爲是在團隊開發中，沒有規範的代碼風格各異，既不利於代碼的閱讀和維護，也會下降整個團度的開發效率，下降代碼的質量。關於android的編碼規範，其實規則都已經比較成熟，這裏總結一下個人開發經歷，做爲專欄的一個開頭！

命名規範

1. 包命名及分包結構規範

   • 包名沿用Java編程的通用風格

2. 類命名規範

   • 基本的類名沿用Java編程的通用風格（採用完整的英文描述符，全部單詞第一個字母大寫，採用駝峯式命名）

   • android特有的類，如Activity、Fragment、Service、Provider、Adapter、View等，則以對應的類型單詞爲後綴

3. 接口命名規範

   • 類命名以大寫字母I爲前綴，若是是監聽接口以Listener結尾

   • 在自定義的監聽接口裏，監聽事件以on開頭,如onOpenMenu(), onRefresh()...

4. 方法命名規範

   • 方法命名沿用Java編程的通用風格（採用完整的英文描述符，函數名字以表明函數功能的英文單詞組成，除首單詞小寫，其餘單詞首字母大寫；通常的，函數第一個單詞要求用動詞）

5. 變量命名規範

   • boolean成員要以is開頭，或以has開頭。如： isFirst, hasMore

   • 控件命名規範： 原則是「view的縮寫 + 功能描述」。 好比一個TextView縮寫爲tv(駝峯命名抽取出來的縮寫)， 這個TextView是顯示用戶名字的， 因此就能夠命名爲: tvUserName。

   • 常量的名字所有大寫，單詞之間用’_’分開

   • 控件命名規範： 原則是「view的縮寫 + 功能描述」。 好比一個TextView縮寫爲tv(駝峯命名抽取出來的縮寫)， 這個TextView是顯示用戶名字的， 因此就能夠命名爲:tvUserName

TextView : tv	EditText : et	Button : btn	ImageButton : ib
ImageView : iv	CheckBox : cb	RadioButton : rb	ProgressBar : pb
Seekbar : sb	ScrollView : sv	ListView : lv	GridView : gv
WebView : wv	ViewPager : vp	ExpandableListView : elv

格式規範

1. 註釋規範

   • 文件頭註釋（文件要加文件頭）

     /** * @author xxxx * @date xxxx年xx月xx日 * Copyright xxxx. All rights reserved. */複製代碼

   • 類／接口註釋(必須註明類／接口的編寫目的、用途)

     /** * 類或接口的做用描述 * @author XXX<email> * @version xxxx-xx-xx（xxxx-xx-xx爲年月日) * Copyright XXXX. All rights reserved. */複製代碼

   • 方法頭註釋

     /** * 方法的描述 * @param 參數的描述 * @return 返回類型的描述 * @exception 異常信息的描述 */複製代碼

   • 方法體註釋

     使用"//"進行註釋，註釋的內容包括：

     • 控制流結構說明
     • 變量說明
     • 複雜代碼說明
     • 處理順序說明

2. 空行使用規範

   • package和import之間要空一行

   • 給不一樣功能的代碼塊之間加上空行， 提高可讀性

3. 括弧使用規範

   • 括號沿用Java風格，即左弧號{是在方法聲明這一行，而不是C++式的另起一行

   • 即便只有一行內容， if/else/for/while等條件或循環，都要加上大括號{ }

4. 代碼位置放置規範

   • Activity以onCreate()做爲第一個方法， 其它類以構造函數作爲第一個方法。 提升可讀性

   • 功能上相近，有調用關係的函數儘可能緊挨在一塊兒

   • Activity、Fragment這些android裏面具有生命週期的類，儘可能把生命週期的方法按順序排到一塊兒，提升可讀性

   • 內部類／接口建議統一放在文件的開頭或者結尾

優化

1. 儘可能不要有重複代碼。 一發現有重複代碼，就要進行重構，抽取出一個公有類/方法

2. 有大量if/else時，考慮下有無可能用策略模式、模板方法模式、面向接口編程來消除這種大量的if/else

3. 一個JavaBean類， 好比就是存一些數據的一個Response類，若是是要開放一個成員給別人用， 這個成員又有getter，又有setter， 那就直接聲明爲public。

4. layout文件中， 層數不要過多， 儘可能控制在6層之內。 固然，層數越少越好。

5. 對於一個佈局文件中的控件具有大量相同的屬性的時候，考慮將這些共同屬性提取稱爲style進行使用

6. 寫佈局文件須要觀察佈局的效果的時候，使用tools:xxx，不要直接使用android:xxx

7. 對於activity中經常使用的本身定義的initView、initData這些方法抽象出來放到對應的基類當中

8. 在設計某些功能、邏輯複雜的類或模塊的時候，建議另外寫一份設計文檔，方便後人理解。

適配

1. 長寬用dp作單位， 通常不推薦用px。 若是有特殊理由， 能夠用px。 好比UED同窗要求一條分隔線就只有1px寬

接下來本身會堅持寫專欄，既是對本身學到的東西的總結， 也是跟你們一塊兒分享學習。歡迎你們關注。個人我的主頁是淺唱android，個人文章也會在上面發佈。謝謝你們寶貴的時間！