開發規范重不重要了，不言而喻。這里就給大家說一故事把——據《聖經·舊約·創世記》第11章記載，是當時人類聯合起來興建，希望能通往天堂的高塔。為了阻止人類的計划，上帝讓人類說不同的語言，使人類相互之間不能溝通，計划因此失敗，人類自此各散東西。此故事試圖為世上出現不同語言和種族提供解釋。好的開發團隊應該是同樣的語言，同樣的理念，同樣的規范去做同一個事情。因此，這里說的開發規范不僅僅在android開發界重要，而且在所有的程序界的重要性也是不言而喻的。
這里說的開發規范分成目錄規范，項目和報名的命名規范，類，方法，變量和常量的命名規范這幾種。
1.目錄規范
目錄規范——你在開發中整體文件夾組織結構。 我這里推薦一種文件夾的組織結構。
Requirement——需求文檔文件夾
Design——設計文檔文件夾
Test——集成測試，系統測試，測試報告，測試清單文件夾
Deployment——發布部署的文件夾
Study——預研，學習資料的文件夾
Src——源碼文件夾
Help——幫助文檔文件夾
這么組織文件有什么好處，就是你一個項目做完以后，您的所有的資料就也完成了。 就像這樣：
這樣的規范，結構一目了然。
在介紹命名規范之前，先介紹一下常見的命名方法。
-
匈牙利命名法。該命名法是在每個變量名的前面加上若干表示數據類型的字符。基本原則是：變量名=屬性+類型+對象描述。如i表示int,所有i開頭的變量命都表示int類型。s表示String,所有變量命以s開頭的都表示String類型變量。
-
駱駝命名法。正如它的名稱所表示的那樣，是指混合使用大小寫字母來構成變量和函數的名字。駝峰命名法跟帕斯卡命名法相似，只是首字母為小寫，如userName。因為看上去像駝峰，因此而得名。
-
帕斯卡命名法 即pascal命名法。做法是首字母大寫，如UserName,常用在類的變量命名中。
- 下划線命名法，下划線法是隨着C語言的出現流行起來的，在UNIX/LIUNX這樣的環境，以及GNU代碼中使用非常普遍。
2.項目和報名命名規范
對於項目和包名命名規范是
包名一律小寫, 少用縮寫和長名；
采用以下規則：
[基本包].[項目名].[模塊名]
包名一般不要超過三級，級別多了費腦子
不得將類直接定義在基本包下，所有項目中的類、接口等都應當定義在各自的項目和模塊包中；
例如：
package com.routemap _information.util;
這樣子的規范，能夠提高項目組織性，從而便於更好的協同開發。
3.類，接口,方法，常量和變量命名規則
Ⅰ類和接口的命名
類或接口名是個一名詞，采用大小寫混合的方式，每個單詞的首字母大寫。盡量使你的類名簡潔而富於描述。使用完整單詞，避免用縮寫詞(除非該縮寫詞被更廣泛使用，像URL，HTML)。
例如：
class Raster;
class ImageSprite;
interface RasterDelegate;
interface Storing;
命名采用單詞組合取名，單詞首字母為大寫，單詞之間可采用“_”下划線進行區分，也可不采用。
根據定義類型首字母加以區分：
Interface：命名首字母加大寫的“I”;
Abstract class：命名首字母加大寫“A”;
Class：無需加
根據功能類型結尾加上功能描述字符串：
頁面類：“Page”，例如“LoginPage”
處理類：“Handle”，例如“LogicHandle”
工廠實現類：“Impl”，例如“FactoryImpl”
動作事件定義類：“Action”，例如“LoginAction”
網絡事件定義類：“Net”，例如“LoginNet”
數據定義類：“Data”，例如“LoginData”
消息處理類：“Msg”，例如“LoginRequestMsg”
資源管理類：“Manager”，例如“ImageManager”
緩存類：“Cache”，例如“UserCache”
參數傳遞類：“Param”，例如“LoginParam”
功能提供類：“Util”，例如“MathUtil”
數據輸入輸出類：“Steam”，例如“CacheOutStream”
類命名不能使用中文字符，不能在命名字符串中出現“0-9”的數值描述和除下划線以外的其他字符描述，命名的字母組合盡量能夠在本身的文字意義上初步了解類的大體功能。
好的類的命名是，不見注釋見名知意。
采用大小寫混合的方式，第一個單詞的首字母小寫，其后單詞的首字母大寫；
Ⅱ變量命名方法
變量名不應以下划線或美元符號開頭；
盡量避免單個字符的變量名，除非是一次性的臨時變量。臨時變量通常被取名為i，j，k，m和n，它們一般用於整型；c，d，e，它們一般用於字符型；
不建議采用匈牙利命名法則，對不易清楚識別出該變量類型的變量應使用類型名或類型名縮寫作其后綴，例如：
Thread animationThread;
String responseStr;
組件或部件變量使用其類型名或類型名縮寫作其后綴，例如：
Command backCommand;
Image barImage；
TextField passwordField;
Player dogSoundPlayer;
集合類型變量，例如數組和矢量，應采用復數命名或使用表示該集合的名詞做后綴：
Image[] images;
Vector requestQueue;
Ⅲ常量命名
全部采用大寫，單詞間用下划線隔開：
static final int MIN_WIDTH = 4;
static final int MAX_WIDTH = 999;
static final int GET_THE_CPU = 1;
Ⅳ方法命名
方法名是一個動詞，采用大小寫混合的方式，第一個單詞的首字母小寫，其后單詞的首字母大寫；取值類可使用get前綴，設值類可使用set前綴，判斷類可使用is(has)前綴。
getName();
setSarry();
isLogon();
能夠遵循這樣的命名規范，相信你的開發會規范許多。
對於方法中一定要加上適當的非空判斷，與try catch 語句等等程序健壯性的判斷。
最后說一下注釋，注釋，是程序維護的靈魂。對於注釋我給出這樣的建議：
原則——對已經不推薦使用的類和方法需要注明@Deprecated，並說明替代的類或者方法；對於針對集合、開關的方法，要在方法注釋中表明是否多線程安全。
Ⅰ文件注釋
所有的源文件都應該在開頭有一個注釋，其中列出文件的版權聲明、文件名、功能描述以及創建、修改記錄：
/*
* Copyright (C) 2009-2014 ROUTEMAP Inc.All Rights Reserved.
*
* FileName：KQQMIDlet.java
*
* Description：簡要描述本文件的內容
*
* History：
* 版本號 作者 日期 簡要介紹相關操作
* 1.0 Iron 2009-01-21 Create
* 1.1 Iron 2009-01-30 Add Logo Screen
**/
Ⅱ類或接口注釋
采用JavaDoc文檔注釋，在類、接口定義之前應當對其進行注釋，包括類、接口的描述、最新修改者、版本號、參考鏈接等：
/**
* 描述
* @author 作者（最新修改者）
* @version 版本號（最新版本號）
* @see 參考的JavaDoc
*/
class Window extends BaseWindow
{
...
}
注：JavaDoc文檔注釋：描述Java的類、接口、構造方法、方法、以及字段。每個文檔注釋都會被置於注釋定界符/**...*/之中，一個注釋對應一個類、接口或成員。該注釋應位於聲明之前。文檔注釋的第一行(/**)不需縮進，隨后的文檔注釋每行都縮進1格(使星號縱向對齊)。
Ⅱ方法注釋
采用JavaDoc文檔注釋，在方法定義之前當對其進行注釋，包括方法的描述、輸入、輸出及返回值說明、拋出異常說明、參考鏈接等：
/**
* 描述
* @param 參數說明：每個參數一行，注明其取值范圍等
* @return 返回值：注釋出失敗、錯誤、異常時的返回情況
* @exception 異常：注釋出什么條件下會引發什么樣的異常
* @see 參考的JavaDoc
*/
public char charAt(int index)
{
...
}
Ⅲ其它注釋(非JavaDoc文檔注釋)
1單行代碼注釋一律使用注釋界定符"//"，例如：
// explain what this means
if(bar > 1)
{
……
}
int isShow = 0;// 是否顯示
2.多行注釋使用注釋界定符"/*...*/"，例如：
/*
* Here is a block comment with
* multiple lines for text comments.
*/
這些命名規范和注釋，看似是微不足道一小步，卻是我們通往專業程序員的一大步。