1.1 目的和要求
為什麼要有編碼規范
編碼規范對於程序員而言尤為重要，有以下幾個原因：
– 一個軟件的生命周期中，80%的花費在於維護
– 幾乎沒有任何一個軟件，在其整個生命周期中，均由最初的開發人員來維護
– 編碼規范可以改善軟件的可讀性，可以讓程序員盡快而徹底地理解新的代碼
– 如果你將源碼作為產品發佈，就需要確任它是否被很好的打包並且清晰無誤，一如你已構建的其它任何產品
為瞭執行規范，每個軟件開發人員必須一致遵守編碼規范。
這是一個強制執行的標準，而不是一個指南。當我們的標準不適應的時候，我們可以討論、修改標準。但是已經制定的標準一定要得到執行。
1.2 檢查列表
|
文件類型 |
序號 |
規范要點 |
參照標準 |
|
JAVA文件 |
1 |
JAVA文件是否有符合規范的版權和版本信息(簡稱“head”)。 |
1.3 |
|
2 |
每次修改JAVA文件後是否在“head”的HISTORY中添加修改信息。 |
1.3 |
|
|
3 |
JAVA文件中“類”，“類變量”，“方法”是否有符合規范的註釋。 |
1.4 |
|
|
4 |
在“方法”的內部是否有一定數量的註釋。 |
1.4 |
|
|
5 |
JAVA文件中的各種元素是否符合JAVA命名規范。 |
1.5 |
|
|
6 |
JAVA文件中整個的書寫格式和元素的先後順序是否規范。 |
1.6 |
1.3 JAVA文件的版權和版本信息(簡稱“頭”)
版權和版本信息必須在 java 文件的開頭，其他不需要出現在 javadoc 的信息也可以包含在這裡。
所有的頭文件都可以自動生成,詳見<關於eclipse創建新類自動添加註釋的說明.rar>
如：
/*
* Author: wufengt
* Created Date:2008-12-1*
|
日期格式: YYYYMMDD |
* History:
* ——————————————————————————
* Date | Author | Change Description
* 20051212| wuf | 優化編碼的格式
* 20051215 | wuf | 再次優化編碼的格式
*/
1.4 JAVA文件的註釋規范
1．Class類的註釋
類的註釋，一般是用來解釋類的，主要包括這個類的功能描述，註意事項和一些重要功能的使用實例。
/**
* 註釋內容
*/
public class CounterSet extends Observable implements Cloneable{
…
}
2．成員變量的註釋
public 的成員變量必須生成文檔（JavaDoc）。proceted、private和 package 定義的成員變量可以使用一般註解也可以使用JavaDoc進行註釋，所有的成員變量都必須有註釋。
// 操作狀態標志：0.新增,1.修改,2.查看
protected long modifyStatus = 0;
/**
* 每一頁的條目數
*/
Public int pageSize = 0;
3．方法的註釋
所有方法都必須用JavaDoc進行註釋，所有的方法都必須有註釋。
/**
* 保存一個session對象
* @param key 變量名稱
* @param val 傳入對應的對象
*/
public void setSessionValue(String key, Object val) {
…
}
4．方法內部的註釋
復雜的方法內部必須有一定數量的註釋，註釋可以使用單行或多行註釋。註釋的內容要清楚、明瞭，含義準確，防止註釋二義性。保持註釋與其描述的代碼相鄰，即註釋的就近原則；對代碼的註釋應放在其上方相鄰位置，不可放在下面；對結構中的每個變量的註釋應放在此變量的右方；同一結構中不同域的註釋要對齊。一般使用兩種註釋方法：
// 註釋一行
/* …… */ 註釋若幹行
5．javadoc註釋標簽語法
@author 對類的說明 標明開發該類模塊的作者
@version 對類的說明 標明該類模塊的版本
@see 對類、屬性、方法的說明 參考轉向，也就是相關主題
@param 對方法的說明 對方法中某參數的說明
@return 對方法的說明 對方法返回值的說明
//@exception 對方法的說明 對方法可能拋出的異常進行說
1.5 JAVA元素的命名規則
一般命名約定：
1) 盡量使用完整的英文描述符
2) 采用適用於相關領域的術語
3) 采用大小寫混合使名字可讀
4) 盡量少用縮寫，但如果用瞭，要明智地使用，且在整個工程中統一
5) 避免使用長的名字（最好小於 15 個字母）
6) 避免使用類似的名字，或者僅僅是大小寫不同的名字
7) 避免使用下劃線（除靜態常量等）
命名規范：
|
元素名稱 |
命名規則 |
示例 |
|
包（Package） |
采用完整的英文描述符，應該都是由小寫字母組成。對於全局包，將你的Internet 域名反轉並接上包名。 |
com.srt.moa.action |
|
類（Class） |
采用完整的英文描述符，所有單詞的第一個字母大寫。 |
Customer, SavingsAccount
|
|
接口（Interface） |
采用完整的英文描述符說明接口封裝，所有單詞的第一個字母大寫。習慣上，名字後面加上後綴 able，ible 或者 er，但這不是必需的。(不需要寫Interface後綴) |
Contactable， Prompter
|
|
異常（Exception） |
通常采用字母 e 表示異常。 |
e |
|
類變量 |
字段采用完整的英文描述，第一個字母小寫，任何中間單詞的首字母大寫. |
firstName, lastName
|
|
局部變量 |
同類變量的命名規則 |
|
|
獲取、設置成員函數 |
獲取成員函數 被訪問字段名的前面加上前綴 get，佈爾型的獲取成員函數 所有的佈爾型獲取函數必須用單詞 is 做前綴。 設置成員函數 被訪問字段名的前面加上前綴 set。(使用eclipse自動生成) |
getFirstName(), getLastName() isPersistent(), isString() setFirstName(), setLastName(), setWarpSpeed()
|
|
普通成員函數 |
普通成員函數 采用完整的英文描述說明成員函數功能，第一個單詞盡可能采用一個生動的動詞，第一個字母小寫。 |
openFile(), addAccount()
|
|
靜態常量字段（static final） |
全部采用大寫字母，單詞之間用下劃線分隔。 |
MIN_BALANCE, DEFAULT_DATE
|
|
循環計數器 |
通常采用字母 i，j，k 或者counter 都可以接受。 |
i, j, k, counter
|
|
數組 |
數組應該總是用下面的方式來命名：byte[] buffer; 而不是： byte buffer[]; |
byte[] buffer |
1.6 JAVA的排版規范和元素的先後順序
1． 排版規范
² 關鍵詞和操作符之間加適當的空格。
² 相對獨立的程序塊與塊之間加空行
² 較長的語句、表達式等要分成多行書寫。
² 劃分出的新行要進行適應的縮進，使排版整齊，語句可讀。
² 長表達式要在低優先級操作符處劃分新行，操作符放在新行之首。
² 循環、判斷等語句中若有較長的表達式或語句，則要進行適應的劃分。
² 若函數或過程中的參數較長，則要進行適當的劃分。
² 不允許把多個短語句寫在一行中，即一行隻寫一條語句。
² 函數或過程的開始、結構的定義及循環、判斷等語句中的代碼都要采用縮進風格。
² JAVA語言是用大括號‘{’和‘}’界定一段程序塊的，編寫程序塊時‘{’和
‘}’應各獨占一行並且位於同一列，同時與引用它們的語句左對齊。在函數體的開始、類的定義、結構的定義、枚舉的定義以及if、for、do、while、switch、case語句中的程序都要采用如上的縮進方式。
if (i>0) { i ++ }; // 錯誤, { 和 } 在同一行
if (i>0)
{
i ++
}; // 正確, { 單獨作為一行
if (i>0) {
i ++
}; // 正確, { 單獨作為一行
2． 元素先後順序
/*版權版本信息 */
Package/Imports
類定義(包含瞭在不同的行的 extends 和 implements public class CounterSet)
extends Observable
implements Cloneable
{
類的成員變量（Class Fields）
構造函數
克隆方法
類方法
存取方法(get/set 方法)
toString 方法
main 方法
}
附件：
Sun公司英文原文（Java的編碼規范）：http://java.sun.com/docs/codeconv/html/CodeConvTOC.doc.html
