| 前言 |
| 代碼規範有什麼意義 |
2.幾乎沒有任何一個軟件，在其整個生命週期中，均由最初的開發人員來維護，代碼規
範減少了工作交接過程中的交流成本。
3.規範可以改善軟件的可讀性，可以讓程序員儘快而徹底地理解新的設計和代碼，節約
了時間，提高了工作效率。
4.良好的編碼規範可以有效避免一些低級錯誤，贏得同事的誇獎和上司的認可。
| 個人經歷 |
| 命名規範 |
1.名字應該能夠標識事物的特性，並且與業務掛鉤。
2.名字一律使用英文單詞，而不能爲拼音。
3.名字可以有兩個或三個單詞組成，但不應多於4個，控制在3至30個字母以內。
4.在名字中，多個單詞用大寫第一個字母（其它字母小寫）來分隔。例如：IsSuperUser。
5.命名避免和以下關鍵字衝突
如：Base，Date，Class……
6.方法名、參數名統一使用駝峯命名法（Camel命名法），除首字母外，其他單詞的首字
母大寫，其他字母小寫，類名每個組合的單詞都要大寫；
正例：localValue/getHttpMessage()/inputUserId
| 註釋規範 |
1.一般情況下，源程序的有效註釋量必須在30%以上。
2.避免使用裝飾性內容，保持註釋的簡潔。
3.註釋信息不僅要包括代碼的功能，還應給出原因，不要爲註釋而註釋。
4.除變量定義等較短語句的註釋可用行尾註釋外，其他註釋當避免使用行尾註釋。
5.註釋類型：javadoc註釋，失效代碼註釋(eclipse下ctrl+shift+/),代碼細節註釋//。
6.對類、方法、變量等的註釋需要符合JavaDoc規範，對每個類、方法都應詳細說明其
功能、條件、參數等，並使用良好的HTML標記
7.格式化註釋，以使生成的JavaDoc易閱讀和理解。
8.如果註釋太複雜說明程序需要修改調整，使設計更加合理。
9.getter、setter方法不用註釋
10.註釋不能嵌套
11.生成開發文檔的需要用中文編寫
12.如果需要註釋的內容太多，需附加文檔進行說明，註釋時加上"參見《****》"
13.距離較遠的}必須註釋
14.複雜的分支流程必須註釋
15.代碼質量不高但能正常運行，或者還沒有實現的代碼用//TODO:聲明
16.存在錯誤隱患的代碼用//FIXME:聲明
| 語句規則 |
原則：
1.統一使用Eclipse格式化工具進行格式化，默認快捷鍵：Ctrl+Shift+F
2.儘量避免強制類型轉換。如果不得不做類型轉換，儘量用顯式方式。
3.Ifelse中的業務代碼行數太長，否則就要考慮用函數封裝
4.避免在表達式中用賦值語句
5.避免對浮點類型做等於或不等於判斷
6.杜絕魔法數字，for循環的最大數等也要用變量代替，以便知道是什麼含義
7.對象比較運算，常量放在前面，比如"aaa".equals(str)
8.Boolean的"假"判斷格式：if(false==isMax)而不用if(!isMax)，因爲非符號"！"不
清晰
9.如果一段帶有業務邏輯的代碼超過兩次用到，就將其封裝成一個方法
10.單個循環也要用{}
11.每個變量僅有一個唯一的用途
12.單個函數執行單個功能並與其命名相符
13.消除所有編譯器警告
14.常數變量聲明爲final
15.每個if-elseif-else語句都有最後一個else以確保處理了全集
16.對於流操作代碼的異常捕獲有finally操作以關閉流對象，比如：
17.對同步對象的遍歷訪問必須進行代碼同步處理
18.在對Map對象使用迭代遍歷過程中保證沒有做增減元素操作
19.Ifelse判斷語句避免頭重腳輕，比如if的代碼段過大，else的代碼很短，這時候要調
整結構。
20.每一行最多包含一條語句。
循環語句：
1.務必檢查，杜絕死循環
2.即使循環體只有一條語句，也要用花括號括起
3.儘量不用空語句，特殊情況用到空語句，寫好註釋，告訴讀者這不是bug
4.循環中禁止使用訪問數據庫的操作，循環內部如果需與數據庫交互，而應提前一次性
讀取出。
比如：Switch-case
1.語句switch中的每個case各佔一行。
2.所有的非空case語句必須用break;語句結束。例：
3.語句switch中的case按字母順序排列。
4.爲所有switch語句提供default分支。
| 編碼風格規則 |
編碼過程中需遵循以下風格習慣：
1.代碼未寫，文檔先行，註釋必須按照固定統一範式撰寫。
2.關係運算必須常量在左、變量在右。
3.不許使用複雜的運算表達式，必要時添加括號而不依賴於優先級。
4.局部變量必須初定義、避免不必要的內存操作、內存操作必須考慮異常處理。
