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

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

目錄

• 1.命名基本原則 
• 2.命名基本規範
• 2.1編程基本命名規範
• 2.2分類命名規範
• 3.分類命名規範
• 3.1基礎資料型別 (Elementary Data Type)命名規範
• 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基礎資料型別 (Elementary Data Type)命名規範

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 模式