Android開發代碼規范，android開發代碼

Android開發代碼規范，android開發代碼

目錄

• 1.命名基本原則 
• 2.命名基本規范
• 2.1編程基本命名規范
• 2.2分類命名規范
• 3.分類命名規范
• 3.1基本數據類型命名規范
• 3.2控件命名規范
• 3.3變量命名規范
• 3.4整個項目的目錄規范化
• 3.4 res資源文件命名規范
• 4.代碼書寫規范 
• 5.注釋
• 6.提高代碼質量
• 7.設計模式（Design Patterns）

 

1.命名基本原則
    在面向對象編程中，對於類，對象，方法，變量等方面的命名是非常有技巧的。比如，大小寫的區分，使用不同字母開頭等等。但究其本，追其源，在為一個資源其名稱的時候，應該本著描述性以及唯一性這兩大特征來命名，才能保證資源之間不沖突，並且每一個都便於記憶。

對於理解應用程序的邏輯流，命名方案是最有影響力的一種幫助。名稱應該說明“什麼”而不是“如何”。命名原則是：使名稱足夠長以便有一定的意義，並且足夠短以避免冗長。唯一名稱在編程上僅用於將各項區分開。以下幾點是規范的命名方法。 
 

2.命名基本規范

2.1編程基本命名規范 
（1）避免難懂的名稱，如屬性名xxK8，這樣的名稱會導致多義性。   
（2） 在面向對象的語言中，在類屬性的名稱中包含類名是多余的，如Book.BookTitle，而是應該使用Book.Title。   
（3）在允許函數重載的語言中，所有重載都應該執行相似的函數。 

（4）使用動詞-名詞的方法來命名對給定對象執行特定操作的例程，如CalculateInvoiceTotal()。（例程是某個系統對外提供的功能接口或服務的集合）   

（5）只要合適，在變量名的末尾或開頭加計算限定符（Avg、Sum、Min、Max、Index）。 
（6）在變量名中使用互補對，如min/max、begin/end和open/close。  

（7）布爾變量名應該包含Is，這意味著Yes/No 或 True/False 值，如 fileIsFound。   

（8）即使對於可能僅出現在幾個代碼行中的生存期很短的變量，仍然使用有意義的名  稱。僅對於短循環索引使用單字母變量名，如 i 或 j。   

（9）為了幫助區分變量和例程，對例程名稱使用Pascal大小寫處理 (CalculateInvoiceTotal)，其中每個單詞的第        一個字母都是大寫的。對於變量名，使用 camel大小寫處理 (documentFormatType)，其中除了第一個單詞外每個單詞的第一個字母都是大寫的。   

（10）不要使用原義數字或原義字符串，而是使用命名常數，NUM_DAYS_IN_WEEK ，以便於維護和理解。  

 

 

 2.2分類命名規范

（1）包的命名 　 

　　Java包的名字都是由小寫單詞組成。但是由於Java面向對象編程的特性，每一名Java程序員都可以編寫屬於自己的Java包，為了保障每個Java包命名的唯一性，在最新的Java編程規范中，要求程序員在自己定義的包的名稱之前加上唯一的前綴。由於互聯網上的域名稱是不會重復的，所以程序員一般采用自己在互聯網上的域名稱作為自己程序包的唯一前綴。 

　　例如： com.pccb.app

（2）類的命名 

　　 類的名字必須由大寫字母開頭而單詞中的其他字母均為小寫；如果類名稱由多個單詞組成，則每個單詞的首字母均應為大寫例如TestPage；如果類名稱中包含單詞縮寫，則這個所寫詞的每個字母均應大寫，如：XMLExample,還有一點命名技巧就是由於類是設計用來代表對象的，所以在命名類時應盡量選擇名詞。 　　

　　例如： Circle 

（3）方法的命名 

　　方法的名字的第一個單詞應以小寫字母作為開頭，後面的單詞則用大寫字母開頭。

　　例如： sendMessge 

（4）常量的命名 

　　常量的名字應該都使用大寫字母，並且指出該常量完整含義。如果一個常量名稱由多個單詞組成，則應該用下劃線來分割這些單詞。

　　例如： MAX_VALUE 

（5）參數的命名 

參數的命名規范和方法的命名規范相同，而且為了避免閱讀程序時造成迷惑，請在盡量保證參數名稱為一個單詞的情況下使參數的命名盡可能明確。 

私有屬性：private int mAge;

靜態變量：static String sName;

函數內部變量：int  _Age;

方法定義時的形參：int pAge;

 

（6）Javadoc注釋 

　　Java除了可以采用我們常見的注釋方式之外，Java語言規范還定義了一種特殊的注釋，也就是我們所說的Javadoc注釋，它是用來記錄我們代碼中的API的。Javadoc注釋是一種多行注釋，以/**開頭，而以*/結束，注釋可以包含一些HTML標記符和專門的關鍵詞。使用Javadoc注釋的好處是編寫的注釋可以被自動轉為在線文檔，省去了單獨編寫程序文檔的麻煩。

　　例如： 

/**

* This is an example of

* Javadoc

*

* @author darchon

* @version 0.1, 10/11/2002

*/ 

　　在每個程序的最開始部分，一般都用Javadoc注釋對程序的總體描述以及版權信息，之後在主程序中可以為每個類、接口、方法、字段添加Javadoc注釋，每個注釋的開頭部分先用一句話概括該類、接口、方法、字段所完成的功能，這句話應單獨占據一行以突出其概括作用，在這句話後面可以跟隨更加詳細的描述段落。在描述性段落之後還可以跟隨一些以Javadoc注釋標簽開頭的特殊段落，例如上面例子中的@auther和@version，這些段落將在生成文檔中以特定方式顯示。

雖然為一個設計低劣的程序添加注釋不會使其變成好的程序，但是如果按照編程規范編寫程序並且為程序添加良好的注釋卻可以幫助你編寫出設計完美，運行效率高且易於理解的程序，尤其是在多人合作完成同一項目時編程規范就變得更加重要。俗話說“磨刀不誤砍柴工”，花費一點時間去適應一下Java編程規范是有好處的。 

 

3.分類命名規范

3.1基本數據類型命名規范

Integer：int+描述          Char：chr+描述          Boolean：bln+描述 

Long：lng+描述           Short：shr +描述         Double：dbl+描述

String：str+描述           Float：flt+描述          Single：sng+描述

DataTime：dt+描述         Array：arr+描述        Object：obj+描述     

如：String  srtName;

 

3.2控件命名規范 

TextView ：txt_+描述 

Button ：btn_+描述  

ImageButton ：imgBtn_+描述

ImageView ：imgView_+描述

CheckBox ：chk_+描述

RadioButton ：rdoBtn_+描述

AnalogClock ：anaClk_+描述 

DigitalClock ：DgtClk_+描述

DatePicker ：dtPk_+描述

TimePicker ：tmPk _+描述

ToggleButton ：tglBtn_+描述

EditText：edtTxt_+描述

ProgressBar：lcb_+描述

SeekBar：skBar _+描述

AutoCompleteTextView：autoTxt_+描述

MultiAutoCompleteTextView：mlAutoTxt_+描述 

ZoomControls：zmCtrl_+描述

Include：ind_+描述 

VideoView：vdoVi_+描述

WebView：webVi_+描述

RatingBar：ratBar_+描述

Tab：tab__+描述

Spinner：spn_+描述

Chronometer：Cmt_+描述

ScrollView：sclVi_+描述

TextSwitcher：txtSwt_+描述  

Gallery：gal_+描述

ImageSwitcher：imgSwt_+描述

GridView：gV_+描述

ListView：lVi_+描述

ExpandableList: epdLt_+描述

MapView: mapVi_+描述

 

控件說明如下：

• TextView - 文本顯示控件

• Button - 按鈕控件

• ImageButton - 圖片按鈕控件

• ImageView - 圖片顯示控件

• CheckBox - 復選框控件

• RadioButton - 單選框控件

• AnalogClock - 鐘表（帶表盤的那種）控件

• DigitalClock - 電子表控件

• DatePicker - 日期選擇控件

• TimePicker - 時間選擇控件

• ToggleButton - 雙狀態按鈕控件

• EditText - 可編輯文本控件

• ProgressBar - 進度條控件

• SeekBar - 可拖動的進度條控件

• AutoCompleteTextView - 支持自動完成功能的可編輯文本控件

• MultiAutoCompleteTextView - 支持自動完成功能的可編輯文本控件，允許輸入多值（多值之間會自動地用指定的分隔符    分開）

• ZoomControls - 放大/縮小按鈕控件

• Include - 整合控件

• VideoView - 視頻播放控件

• WebView - 浏覽器控件

• RatingBar - 評分控件

• Tab - 選項卡控件

• Spinner - 下拉框控件

• Chronometer - 計時器控件

• ScrollView - 滾動條控件

• TextSwitcher - 文字轉換器控件（改變文字時增加一些動畫效果）

• Gallery –畫廊控件

• ImageSwitcher - 圖片轉換器控件（改變圖片時增加一些動畫效果）

• GridView - 網格控件

• ListView - 列表控件

• ExpandableList - 支持展開/收縮功能的列表控件        

 

3.3變量命名規范

變量命名：前綴+類型描述+意義描述

前綴：

成員變量：m_***             局部變量：l_***          形參：a_***

常量：大寫_***                  枚舉值：em_***

 

3.4整個項目的目錄規范化

1、系統目錄規范：

　　指項目目錄中不僅包括源代碼，還需要包括：需求相關文檔、設計文檔、計劃日志文檔、測試文檔、項目進行中學習資料文檔（參考Demo）；使整個項目更加清晰，

2、源代碼目錄規范：

一般系統命名空間目錄盡量不要超過3層，[組織名].[項目名].[模塊名]：com.pccb.app

 

3.5 res資源文件命名

 1,res/layout下的xml文件統一用小寫和下劃線"_"組合命名，並加上前綴以便區分 

正例：

對話框的xml配置文件:dlg_name.xml

 2.layout中的id采用以下命名模式： view縮寫_模塊名稱_view的邏輯名稱

     說明：view的縮寫詳情如下 

ListView： lv 

RelativeView: rv 

TextView: tv 

ImageView: iv

 ImageButton: ib  / ibtn

Button:  btn 

正例： 

@＋id/lv_appstore_applist 

反例： 

@+id/ListView01

 3.activity文中的view變量采用以下命名模式： 邏輯名稱_view縮寫

   正例： 

ListViewapplistLv 

 4.res/drawable下的資源文件采用以下命名模式：  activity名稱_邏輯名稱/common_邏輯名稱

   正例： 

main_default.png,main_pressed.png

 5.strings.xml中的id采用以下命名模式： activity名稱_功能模塊名稱_邏輯名稱/activity名稱_邏輯名稱/common_邏輯名稱

   正例： 

<string name="main_downloading">正在下載„</string>

 6.字符串信息應統一在strings.xml中定義，調試信息除外

 7.使用日志時，不重要的信息定義在debug等級或者info等級，較為嚴重的情況把日志定義的warn等級和error等級。正常情況下盡量不使用System.out.println();作為日志的輸出

4.代碼書寫規范 
（1）建立標准的縮進大小（如四個空格），並一致地使用此標准。用規定的縮進對齊代碼節。    
（2）在括號對對齊的位置垂直對齊左括號和右括號，如：   
   for   (i=0; i<100; i++) 
   { 
         ; 
   }    
（3）沿邏輯結構行縮進代碼使代碼更易於閱讀和理解，如：   
   if(expression) 
         { 
         if(expression ) 
          { 
            // 
            //此處填寫你的代碼塊; 
            // 
          } 
         else 
          { 
            // 
            //此處填寫你的代碼塊; 
            // 
          } 
         } 
（4）為注釋和代碼建立最大的行長度，以避免不得不滾動源代碼編輯器，並且可以提供整齊的硬拷貝表示形式。     
（5）當一行內容太長而必須換行時，在後面換行代碼中要使用縮進格式，如下： 
    string   inserString ="Insert   Into   TableName(username,password,email,sex,address) " 
    +"Values( 'Soholife ', 'chenyp ', 'soholife@sina.com ', 'male ', '深圳福田 ') "; 
（6）每一行上放置的語句避免超過一條。特殊循環如for(i =0;i<100;i++)等除外。   
（7）編寫SQL語句時，對於關鍵字使用全部大寫，對於數據庫元素（如表、列和視圖）使用大小寫混合。例如SELECT * FROM Table1；  
（8）將每個主要的SQL子句放在不同的行上，這樣更容易閱讀和編輯語句，例如：   

   SELECT   FirstName,   LastName 
   FROM     Customers 
   WHERE   State   =   'WA '  

（10）使用空白為源代碼提供結構線索。這樣做會創建代碼“段”，有助於讀者理解軟件的邏輯分段
（11）將大的復雜代碼段分為較小的、易於理解的模塊。   

5.注釋 
     軟件文檔以兩種形式存在：外部的和內部的。外部文檔（如規范、幫助文件和設計文檔）在源代碼的外部維護。內部文檔由開發人員在開發時在源代碼中編寫的注釋組成。 
     不考慮外部文檔的可用性，由於硬拷貝文檔可能會放錯地方，源代碼清單應該能夠獨立存在。外部文檔應該由規范、設計文檔、更改請求、錯誤歷史記錄和使用的編碼標准組成。   以下幾點是規范的注釋方法：   

（1）一個工程應有一個統一的頭文件注釋，以說明整個工程的信息、創建日期、版本等等     

（2）對重要的程序加注釋進行說明

（3）修改代碼或刪除時，將原代碼用注釋的方法屏蔽，同時要加開發者自身對修改操作的注釋。格式為：

//原代碼

//Added/（Modified/ Deleted） by 開發者姓名 年-月-日;

//因為業務原因修改的，要注明修改或刪除原因）

新代碼
（4）使用XML文檔格式，如下面方法的注釋： 
  <!-- 注釋內容 -->

（5）避免雜亂的注釋，而是應該使用空白將注釋同代碼分開。   
（6）移除所有臨時或無關的注釋，以避免在日後的維護工作中產生混亂。   
（7）注釋應對代碼進行准確的說明，不應存在歧義。   
（8）在整個應用程序中，使用具有一致的標點和結構的統一樣式來構造注釋。   

（9）方法注釋的內容（1，5，6，7項正常情況下都要寫上去）  

1.類該方法是做什麼的。 2.該方法如何工作。 3.代碼修改歷史紀錄。 4.方法調用代碼示范。 

5.必須傳入什麼樣的參數給這個方法。@param 6.異常處理。@throws 

7.這個方法返回什麼。@return

 

6.提高代碼質量

（1）刪除無用的變量

（2）刪除無用的引入 

（3）對於可以復用的部分，一定提取成共用的方法，減少代碼量

（4）變量/方法命名一定要符合清晰易懂，不用太在乎長度

（5）代碼完成後，進行code review，減少出錯幾率 

 (6)  用適合的方式盡量去思考設計模式方式來進行開發

 

 

7.設計模式（Design Patterns）——可復用面向對象軟件的基礎

   設計模式（Design pattern）是一套被反復使用、多數人知曉的、經過分類編目的、代碼設計經驗的總結。使用設計模式是為了可重用代碼、讓代碼更容易被他人理解、保證代碼可靠性。 毫無疑問，設計模式於己於他人於系統都是多贏的，設計模式使代碼編制真正工程化，設計模式是軟件工程的基石，如同大廈的一塊塊磚石一樣。項目中合理的運用設計模式可以完美的解決很多問題，每種模式在現在中都有相應的原理來與之對應，每一個模式描述了一個在我們周圍不斷重復發生的問題，以及該問題的核心解決方案，這也是它能被廣泛應用的原因。

   一個程序員對設計模式的理解:
      “不懂”為什麼要把很簡單的東西搞得那麼復雜。後來隨著軟件開發經驗的增加才開始明白我所看到的“復雜”恰恰就是設計模式的精髓所在，我所理解的“簡單”就是一把鑰匙開一把鎖的模式，目的僅僅是著眼於解決現在的問題，而設計模式的“復雜”就在於它是要構造一個“萬能鑰匙”，目的是提出一種對所有鎖的開鎖方案。在真正理解設計模式之前我一直在編寫“簡單”的代碼.
    這個“簡單”不是功能的簡單，而是設計的簡單。簡單的設計意味著缺少靈活性，代碼很鋼硬，只在這個項目裡有用，拿到其它的項目中就是垃圾，我將其稱之為“一次性代碼”。

    -->要使代碼可被反復使用,請用'設計模式'對你的代碼進行設計.

很多我所認識的程序員在接觸到設計模式之後，都有一種相見恨晚的感覺，有人形容學習了設計模式之後感覺自己好像已經脫胎換骨，達到了新的境界，還有人甚至把是否了解設計模式作為程序員劃分水平的標准。

我們也不能陷入模式的陷阱，為了使用模式而去套模式，那樣會陷入形式主義。我們在使用模式的時候，一定要注意模式的意圖（intent），而不 要過多的去關注模式的實現細節，因為這些實現細節在特定情況下，可能會發生一些改變。不要頑固地認為設計模式一書中的類圖或實現代碼就代表了模式本身。

設計原則：(重要)
    1.邏輯代碼獨立到單獨的方法中，注重封裝性--易讀，易復用。
不要在一個方法中，寫下上百行的邏輯代碼。把各小邏輯代碼獨立出來，寫於其它方法中，易讀其可重復調用。
    2.寫類，寫方法，寫功能時，應考慮其移植性，復用性：防止一次性代碼！
是否可以拿到其它同類事物中應該？是否可以拿到其它系統中應該？
    3.熟練運用繼承的思想：
找出應用中相同之處，且不容易發生變化的東西，把它們抽取到抽象類中，讓子類去繼承它們；
繼承的思想，也方便將自己的邏輯建立於別人的成果之上。如ImageField extends JTextField；
熟練運用接口的思想：
找出應用中可能需要變化之處，把它們獨立出來，不要和那些不需要變化的代碼混在一起。

 

設計模式：

    1.java的23中設計模式 

    2.MVC模式 

    3.MVP 模式