java編碼規范

Ⅰ java軟體開發的代碼規范

1、組織與風格
(1).關鍵詞和操作符之間加適當的空格。
(2).相對獨立的程序塊與塊之間加空行
(3).較長的語句、表達式等要分成多行書寫。
(4).劃分出的新行要進行適應的縮進，使排版整齊，語句可讀。
(5).長表達式要在低優先順序操作符處劃分新行，操作符放在新行之首。
(6).循環、判斷等語句中若有較長的表達式或語句，則要進行適應的劃分。
(7).若函數或過程中的參數較長，則要進行適當的劃分。
(8).不允許把多個短語句寫在一行中，即一行只寫一條語句。
(9).函數或過程的開始、結構的定義及循環、判斷等語句中的代碼都要採用縮進風格。
註：如果大家有興趣可以到安安DIY創作室博客，有相關說明性的文章和解釋。
2、註解
Java 的語法與 C++ 及為相似，那麼，你知道 Java 的注釋有幾種嗎？是兩種？
// 注釋一行
/* ...... */ 注釋若干行
不完全對，除了以上兩種之外，還有第三種，文檔注釋：
/** ...... */ 注釋若干行，並寫入 javadoc 文檔
注釋要簡單明了。
String userName = null; //用戶名
邊寫代碼邊注釋，修改代碼同時修改相應的注釋，以保證注釋與代碼的一致性。
在必要的地方注釋，注釋量要適中。注釋的內容要清楚、明了，含義准確，防止注釋二義性。
保持注釋與其描述的代碼相鄰，即注釋的就近原則。
對代碼的注釋應放在其上方相鄰位置，不可放在下面。對數據結構的注釋應放在其上方相鄰位置，不可放在下面；對結構中的每個域的注釋應放在此域的右方；
同一結構中不同域的注釋要對齊。
變數、常量的注釋應放在其上方相鄰位置或右方。
全局變數要有較詳細的注釋，包括對其功能、取值范圍、哪些函數或過程存取它以及存取時注意事項等的說明。
在每個源文件的頭部要有必要的注釋信息，包括：文件名；版本號；作者；生成日期；模塊功能描述（如功能、主要演算法、內部各部分之間的關系、該文件與其它文件關系等）；主要函數或過程清單及本文件歷史修改記錄等。
/**
* Copy Right Information : Neusoft IIT
* Project : eTrain
* JDK version used : jdk1.3.1
* Comments : config path
* Version : 1.01
* Modification history :2003.5.1
* Sr Date Modified By Why & What is modified
* 1. 2003.5.2 Kevin Gao new
**/
在每個函數或過程的前面要有必要的注釋信息，包括：函數或過程名稱；功能描述；輸入、輸出及返回值說明；調用關系及被調用關系說明等
/**
* Description :checkout 提款
* @param Hashtable cart info
* @param OrderBean order info
* @return String
*/
public String checkout(Hashtable htCart,
OrderBean orderBean)
throws Exception{
}
javadoc注釋標簽語法
@author 對類的說明 標明開發該類模塊的作者
@version 對類的說明 標明該類模塊的版本
@see 對類、屬性、方法的說明 參考轉向，也就是相關主題
@param 對方法的說明 對方法中某參數的說明
@return 對方法的說明 對方法返回值的說明
@exception 對方法的說明 對方法可能拋出的異常進行說明
3、命名規范
定義這個規范的目的是讓項目中所有的文檔都看起來像一個人寫的，增加可讀性，減少項目組中因為換人而帶來的損失。（這些規范並不是一定要絕對遵守，但是一定要讓程序有良好的可讀性）較短的單詞可通過去掉母音形成縮寫；要不然最後自己寫的代碼自己都看不懂了，那可不行。
較長的單詞可取單詞的頭幾發符的優先順序，並用括弧明確表達式的操作順序，避免使用默認優先順序。
使用匈牙利表示法
Package 的命名
Package 的名字應該都是由一個小寫單片語成。
package com.neu.util
Class 的命名
Class 的名字必須由大寫字母開頭而其他字母都小寫的單片語成,對於所有標識符，其中包含的所有單詞都應緊靠在一起，而且大寫中間單詞的首字母。
public class ThisAClassName{}
Class 變數的命名
變數的名字必須用一個小寫字母開頭。後面的單詞用大寫字母開頭
userName , thisAClassMethod
Static Final 變數的命名
static Final 變數的名字應該都大寫，並且指出完整含義。
/**
*DBConfig PATH
**/
public static final String
DB_CONFIG_FILE_PATH =com.neu.etrain.dbconfig;
參數的命名
參數的名字必須和變數的命名規范一致。
數組的命名
數組應該總是用下面的方式來命名：
byte[] buffer;
而不是：
byte buffer[];
方法的參數
使用有意義的參數命名，如果可能的話，使用和要賦值的欄位一樣的名字：
SetCounter(int size){
this.size = size;
}
4、文件樣式
所有的 Java(*.java) 文件都必須遵守如下的樣式規則：
版權信息
版權信息必須在 java 文件的開頭，比如：
/*
* Copyright ? 2000 Shanghai XXX Co. Ltd.
* All right reserved.
*/
其他不需要出現在 javadoc 的信息也可以包含在這里。
Package/Imports
package 行要在 import 行之前，import 中標準的包名要在本地的包名之前，而且按照字母
順序排列。如果 import 行中包含了同一個包中的不同子目錄，則應該用 * 來處理。
package hotlava.net.stats;
import java io.*;
import java.util.Observable;
import hotlava.util.Application;
這里 java。io.* 使用來代替InputStream and OutputStream 的。
Class
接下來的是類的注釋，一般是用來解釋類的。
/**
* A class representing a set of packet and byte counters
* It is observable to allow it to be watched, but only
* reports changes when the current set is complete
*/
接下來是類定義，包含了在不同的行的 extends 和 implements
public class CounterSet
extends Observable
implements Cloneable
Class Fields
接下來是類的成員變數：
/**
* Packet counters
*/
protected int[] packets;
public 的成員變數必須生成文檔（JavaDoc）。proceted、private和 package 定義的成
員變數如果名字含義明確的話，可以沒有注釋。
存取方法
接下來是類變數的存取的方法。它只是簡單的用來將類的變數賦值獲取值的話，可以簡單的
寫在一行上。
/**
* Get the counters
* @return an array containing the statistical data. This array has been
* freshly allocated and can be modified by the caller.
*/
public int[] getPackets() { return Array(packets, offset); }
public int[] getBytes() { return Array(bytes, offset); }
public int[] getPackets() { return packets; }
public void setPackets(int[] packets) { this.packets = packets; }
其它的方法不要寫在一行上
構造函數
接下來是構造函數，它應該用遞增的方式寫（比如：參數多的寫在後面）。
訪問類型 (public, private 等.) 和 任何 static, final 或 synchronized 應該在一行
中，並且方法和參數另寫一行，這樣可以使方法和參數更易讀。
public
CounterSet(int size){
this.size = size;
}
克隆方法
如果這個類是可以被克隆的，那麼下一步就是 clone 方法：
public
Object clone() {
try {
CounterSet obj = (CounterSet)super.clone();
obj.packets = (int[])packets.clone();
obj.size = size;
return obj;
}catch(CloneNotSupportedException e) {
throw new InternalError(Unexpected CloneNotSUpportedException: +
e.getMessage());
}
}
類方法
下面開始寫類的方法：
/**
* Set the packet counters
* (such as when restoring from a database)
*/
protected final
void setArray(int[] r1, int[] r2, int[] r3, int[] r4)
throws IllegalArgumentException
{
//
// Ensure the arrays are of equal size
//
if (r1.length != r2.length || r1.length != r3.length || r1.length != r4.length)
throw new IllegalArgumentException(Arrays must be of the same size);
System.array(r1, 0, r3, 0, r1.length);
System.array(r2, 0, r4, 0, r1.length);
}
toString 方法
無論如何，每一個類都應該定義 toString 方法：
public
String toString() {
String retval = CounterSet: ;
for (int i = 0; i < data.length(); i++) {
retval += data.bytes.toString();
retval += data.packets.toString();
}
return retval;
}
}
main 方法
如果main(String[]) 方法已經定義了, 那麼它應該寫在類的底部.
5、代碼可讀性
避免使用不易理解的數字，用有意義的標識來替代。
不要使用難懂的技巧性很高的語句。
源程序中關系較為緊密的代碼應盡可能相鄰。
6、代碼性能
在寫代碼的時候，從頭至尾都應該考慮性能問題。這不是說時間都應該浪費在優化代碼上，而是我們時刻應該提醒自己要注意代碼的效率。比如：如果沒有時間來實現一個高效的演算法，那麼我們應該在文檔中記錄下來，以便在以後有空的時候再來實現她。
不是所有的人都同意在寫代碼的時候應該優化性能這個觀點的，他們認為性能優化的問題應該在項目的後期再去考慮，也就是在程序的輪廓已經實現了以後。
不必要的對象構造
不要在循環中構造和釋放對象
使用 StringBuffer 對象
在處理 String 的時候要盡量使用 StringBuffer 類，StringBuffer 類是構成 String 類的基礎。
String 類將 StringBuffer 類封裝了起來，（以花費更多時間為代價）為開發人員提供了一個安全的介面。當我們在構造字元串的時候，我們應該用 StringBuffer 來實現大部分的工作，當工作完成後將 StringBuffer 對象再轉換為需要的 String 對象。比如：如果有一個字元串必須不斷地在其後添加許多字元來完成構造，那麼我們應該使用StringBuffer 對象和她的 append() 方法。如果我們用 String 對象代替StringBuffer 對象的話，會花費許多不必要的創建和釋放對象的 CPU 時間。大家可以來安安DIY創作室一起討論。
避免太多的使用 synchronized 關鍵字避免不必要的使用關鍵字 synchronized，應該在必要的時候再使用她，這是一個避免死鎖的好方法。
7、編程技巧
byte 數組轉換到 characters
為了將 byte 數組轉換到 characters，你可以這么做：
Hello world!.getBytes();
Utility 類
Utility 類（僅僅提供方法的類）應該被申明為抽象的來防止被繼承或被初始化。
初始化
下面的代碼是一種很好的初始化數組的方法：
objectArguments = new Object[] { arguments };
枚舉類型
JAVA 對枚舉的支持不好，但是下面的代碼是一種很有用的模板：
class Colour {
public static final Colour BLACK = new Colour(0, 0, 0);
public static final Colour RED = new Colour(0xFF, 0, 0);
public static final Colour GREEN = new Colour(0, 0xFF, 0);
public static final Colour BLUE = new Colour(0, 0, 0xFF);
public static final Colour WHITE = new Colour(0xFF, 0xFF, 0xFF);
}
這種技術實現了RED, GREEN, BLUE 等可以象其他語言的枚舉類型一樣使用的常量。
他們可以用 '==' 操作符來比較。
但是這樣使用有一個缺陷：如果一個用戶用這樣的方法來創建顏色 BLACK new Colour(0,0,0)
那麼這就是另外一個對象，'=='操作符就會產生錯誤。她的 equal() 方法仍然有效。由於這個原因，這個技術的缺陷最好註明在文檔中，或者只在自己的包中使用。
8、編寫格式
代碼樣式
代碼應該用 unix 的格式，而不是 windows 的（比如：回車變成回車+換行）
文檔化
必須用 javadoc 來為類生成文檔。不僅因為它是標准，這也是被各種 java 編譯器都認可的方法。使用 @author 標記是不被推薦的，因為代碼不應該是被個人擁有的。
縮進
縮進應該是每行2個空格. 不要在源文件中保存Tab字元. 在使用不同的源代碼管理工具時Tab字元將因為用戶設置的不同而擴展為不同的寬度.如果你使用 UltrEdit 作為你的 Java 源代碼編輯器的話，你可以通過如下操作來禁止保存Tab字元, 方法是通過 UltrEdit中先設定 Tab 使用的長度室2個空格，然後用 Format|Tabs to Spaces 菜單將 Tab 轉換為空格。
頁寬
頁寬應該設置為80字元. 源代碼一般不會超過這個寬度, 並導致無法完整顯示, 但這一設置也可以靈活調整. 在任何情況下, 超長的語句應該在一個逗號或者一個操作符後折行. 一條語句折行後, 應該比原來的語句再縮進2個字元.
{} 對
{} 中的語句應該單獨作為一行. 例如, 下面的第1行是錯誤的, 第2行是正確的:
if (i>0) { i ++ }; // 錯誤, { 和 } 在同一行
if (i>0) {
i ++
}; // 正確, { 單獨作為一行
} 語句永遠單獨作為一行.如果 } 語句應該縮進到與其相對應的 { 那一行相對齊的位置。
括弧
左括弧和後一個字元之間不應該出現空格, 同樣, 右括弧和前一個字元之間也不應該出現空格. 下面的例子說明括弧和空格的錯誤及正確使用:
CallProc( AParameter ); // 錯誤
CallProc(AParameter); // 正確
不要在語句中使用無意義的括弧. 括弧只應該為達到某種目的而出現在源代碼中。下面的例子說明錯誤和正確的用法:
if ((I) = 42) { // 錯誤 - 括弧毫無意義
if (I == 42) or (J == 42) then // 正確 - 的確需要括弧
9、代碼編譯
1.編寫代碼時要注意隨時保存，並定期備份，防止由於斷電、硬碟損壞等原因造成代碼丟失。
2.同一項目組內，最好使用相同的編輯器，並使用相同的設置選項。
3.合理地設計軟體系統目錄，方便開發人員使用。
4.打開編譯器的所有告警開關對程序進行編譯。
5.在同一項目組或產品組中，要統一編譯開關選項。
6.使用工具軟體（如Visual SourceSafe）對代碼版本進行維護。如果大家有不明白的可以到安安DIY創作室留言。
10、可移植性
Borland Jbulider 不喜歡 synchronized 這個關鍵字，如果你的斷點設在這些關鍵字的作用域內的話，調試的時候你會發現的斷點會到處亂跳，讓你不知所措。除非必須，盡量不要使用。
換行
如果需要換行的話，盡量用 println 來代替在字元串中使用 。
你不要這樣：
System.out.print(Hello,world! );
要這樣：
System.out.println(Hello,world!);
或者你構造一個帶換行符的字元串，至少要象這樣：
String newline = System.getProperty(line.separator);
System.out.println(Hello world + newline);
PrintStream
PrintStream 已經被不贊成（deprecated）使用，用 PrintWrite 來代替它。

Ⅱ java編程規范

不需要，沒必要加空格。

Ⅲ Java編碼規范存在的意義是什麼

1、好的編碼規范可以盡可能的減少一個軟體的維護成本，並且幾乎沒有任何專一個軟體屬，在其整個生命周期中，均由最初的開發人員來維護；
2、好的編碼規范可以改善軟體的可讀性，可以讓開發人員盡快而徹底地理解新的代碼；
3、好的編碼規范可以最大限度的提高團隊開發的合作效率；
4、長期的規范性編碼還可以讓開發人員養成好的編碼習慣，甚至鍛煉出更加嚴謹的思維；

Ⅳ 怎樣使JAVA代碼規范

方法命名用駝峰命名法啊，equals比較的時候，字面量放前面，

Ⅳ java編碼規范有哪些

盡量使用完整的英文描述符，採用適用於相關領域的術語，採用大小寫混合使名字可讀。

Ⅵ JAVA編碼規范

(1) 類名首字母應該大寫。欄位、方法以及對象（句柄）的首字母應小寫。對於所有標識符，其中包含的所有單詞都應緊靠在一起，而且大寫中間單詞的首字母。例如：
ThisIsAClassName
thisIsMethodOrFieldName
若在定義中出現了常數初始化字元，則大寫static final基本類型標識符中的所有字母。這樣便可標志出它們屬於編譯期的常數。
Java包（Package）屬於一種特殊情況：它們全都是小寫字母，即便中間的單詞亦是如此。對於域名擴展名稱，如com，org，net或者e等，全部都應小寫（這也是Java 1.1和Java 1.2的區別之一）。
(2) 為了常規用途而創建一個類時，請採取"經典形式"，並包含對下述元素的定義：
equals()
hashCode()
toString()
clone()（implement Cloneable）
implement Serializable
(3) 對於自己創建的每一個類，都考慮置入一個main()，其中包含了用於測試那個類的代碼。為使用一個項目中的類，我們沒必要刪除測試代碼。若進行了任何形式的改動，可方便地返回測試。這些代碼也可作為如何使用類的一個示例使用。
(4) 應將方法設計成簡要的、功能性單元，用它描述和實現一個不連續的類介面部分。理想情況下，方法應簡明扼要。若長度很大，可考慮通過某種方式將其分割成較短的幾個方法。這樣做也便於類內代碼的重復使用（有些時候，方法必須非常大，但它們仍應只做同樣的一件事情）。
(5) 設計一個類時，請設身處地為客戶程序員考慮一下（類的使用方法應該是非常明確的）。然後，再設身處地為管理代碼的人考慮一下（預計有可能進行哪些形式的修改，想想用什麼方法可把它們變得更簡單）。
(6) 使類盡可能短小精悍，而且只解決一個特定的問題。下面是對類設計的一些建議：
一個復雜的開關語句：考慮採用"多形"機制
數量眾多的方法涉及到類型差別極大的操作：考慮用幾個類來分別實現
許多成員變數在特徵上有很大的差別：考慮使用幾個類
(7) 讓一切東西都盡可能地"私有"--private。可使庫的某一部分"公共化"（一個方法、類或者一個欄位等等），就永遠不能把它拿出。若強行拿出，就可能破壞其他人現有的代碼，使他們不得不重新編寫和設計。若只公布自己必須公布的，就可放心大膽地改變其他任何東西。在多線程環境中，隱私是特別重要的一個因素--只有private欄位才能在非同步使用的情況下受到保護。
(8) 謹惕"巨大對象綜合症"。對一些習慣於順序編程思維、且初涉OOP領域的新手，往往喜歡先寫一個順序執行的程序，再把它嵌入一個或兩個巨大的對象里。根據編程原理，對象表達的應該是應用程序的概念，而非應用程序本身。
(9) 若不得已進行一些不太雅觀的編程，至少應該把那些代碼置於一個類的內部。
(10) 任何時候只要發現類與類之間結合得非常緊密，就需要考慮是否採用內部類，從而改善編碼及維護工作（參見第14章14.1.2小節的"用內部類改進代碼"）。
(11) 盡可能細致地加上注釋，並用javadoc注釋文檔語法生成自己的程序文檔。
(12) 避免使用"魔術數字"，這些數字很難與代碼很好地配合。如以後需要修改它，無疑會成為一場噩夢，因為根本不知道"100"到底是指"數組大小"還是"其他全然不同的東西"。所以，我們應創建一個常數，並為其使用具有說服力的描述性名稱，並在整個程序中都採用常數標識符。這樣可使程序更易理解以及更易維護。
(13) 涉及構建器和異常的時候，通常希望重新丟棄在構建器中捕獲的任何異常--如果它造成了那個對象的創建失敗。這樣一來，調用者就不會以為那個對象已正確地創建，從而盲目地繼續。
(14) 客戶程序員用完對象以後，若你的類要求進行任何清除工作，可考慮將清除代碼置於一個良好定義的方法里，採用類似於cleanup()這樣的名字，明確表明自己的用途。除此以外，可在類內放置一個boolean（布爾）標記，指出對象是否已被清除。在類的finalize()方法里，請確定對象已被清除，並已丟棄了從RuntimeException繼承的一個類（如果還沒有的話），從而指出一個編程錯誤。在採取象這樣的方案之前，請確定finalize()能夠在自己的系統中工作（可能需要調用System.runFinalizersOnExit(true)，從而確保這一行為）。
(15) 在一個特定的作用域內，若一個對象必須清除（非由垃圾收集機制處理），請採用下述方法：初始化對象；若成功，則立即進入一個含有finally從句的try塊，開始清除工作。
(16) 若在初始化過程中需要覆蓋（取消）finalize()，請記住調用super.finalize()（若Object屬於我們的直接超類，則無此必要）。在對finalize()進行覆蓋的過程中，對super.finalize()的調用應屬於最後一個行動，而不應是第一個行動，這樣可確保在需要基礎類組件的時候它們依然有效。
(17) 創建大小固定的對象集合時，請將它們傳輸至一個數組（若准備從一個方法里返回這個集合，更應如此操作）。這樣一來，我們就可享受到數組在編譯期進行類型檢查的好處。此外，為使用它們，數組的接收者也許並不需要將對象"造型"到數組里。
(18) 盡量使用interfaces，不要使用abstract類。若已知某樣東西准備成為一個基礎類，那麼第一個選擇應是將其變成一個interface（介面）。只有在不得不使用方法定義或者成員變數的時候，才需要將其變成一個abstract（抽象）類。介面主要描述了客戶希望做什麼事情，而一個類則致力於（或允許）具體的實施細節。
(19) 在構建器內部，只進行那些將對象設為正確狀態所需的工作。盡可能地避免調用其他方法，因為那些方法可能被其他人覆蓋或取消，從而在構建過程中產生不可預知的結果（參見第7章的詳細說明）。
(20) 對象不應只是簡單地容納一些數據；它們的行為也應得到良好的定義。
(21) 在現成類的基礎上創建新類時，請首先選擇"新建"或"創作"。只有自己的設計要求必須繼承時，才應考慮這方面的問題。若在本來允許新建的場合使用了繼承，則整個設計會變得沒有必要地復雜。
(22) 用繼承及方法覆蓋來表示行為間的差異，而用欄位表示狀態間的區別。一個非常極端的例子是通過對不同類的繼承來表示顏色，這是絕對應該避免的：應直接使用一個"顏色"欄位。
(23) 為避免編程時遇到麻煩，請保證在自己類路徑指到的任何地方，每個名字都僅對應一個類。否則，編譯器可能先找到同名的另一個類，並報告出錯消息。若懷疑自己碰到了類路徑問題，請試試在類路徑的每一個起點，搜索一下同名的.class文件。
(24) 在Java 1.1 AWT中使用事件"適配器"時，特別容易碰到一個陷阱。若覆蓋了某個適配器方法，同時拼寫方法沒有特別講究，最後的結果就是新添加一個方法，而不是覆蓋現成方法。然而，由於這樣做是完全合法的，所以不會從編譯器或運行期系統獲得任何出錯提示--只不過代碼的工作就變得不正常了。
(25) 用合理的設計方案消除"偽功能"。也就是說，假若只需要創建類的一個對象，就不要提前限制自己使用應用程序，並加上一條"只生成其中一個"注釋。請考慮將其封裝成一個"獨生子"的形式。若在主程序里有大量散亂的代碼，用於創建自己的對象，請考慮採納一種創造性的方案，將些代碼封裝起來。
(26) 警惕"分析癱瘓"。請記住，無論如何都要提前了解整個項目的狀況，再去考察其中的細節。由於把握了全局，可快速認識自己未知的一些因素，防止在考察細節的時候陷入"死邏輯"中。
(27) 警惕"過早優化"。首先讓它運行起來，再考慮變得更快--但只有在自己必須這樣做、而且經證實在某部分代碼中的確存在一個性能瓶頸的時候，才應進行優化。除非用專門的工具分析瓶頸，否則很有可能是在浪費自己的時間。性能提升的隱含代價是自己的代碼變得難於理解，而且難於維護。
(28) 請記住，閱讀代碼的時間比寫代碼的時間多得多。思路清晰的設計可獲得易於理解的程序，但注釋、細致的解釋以及一些示例往往具有不可估量的價值。無論對你自己，還是對後來的人，它們都是相當重要的。如對此仍有懷疑，那麼請試想自己試圖從聯機Java文檔里找出有用信息時碰到的挫折，這樣或許能將你說服。
(29) 如認為自己已進行了良好的分析、設計或者實施，那麼請稍微更換一下思維角度。試試邀請一些外來人士--並不一定是專家，但可以是來自本公司其他部門的人。請他們用完全新鮮的眼光考察你的工作，看看是否能找出你一度熟視無睹的問題。採取這種方式，往往能在最適合修改的階段找出一些關鍵性的問題，避免產品發行後再解決問題而造成的金錢及精力方面的損失。
(30) 良好的設計能帶來最大的回報。簡言之，對於一個特定的問題，通常會花較長的時間才能找到一種最恰當的解決方案。但一旦找到了正確的方法，以後的工作就輕松多了，再也不用經歷數小時、數天或者數月的痛苦掙扎。我們的努力工作會帶來最大的回報（甚至無可估量）。而且由於自己傾注了大量心血，最終獲得一個出色的設計方案，成功的快感也是令人心動的。堅持抵制草草完工的誘惑－－那樣做往往得不償失。

Ⅶ java程序員有哪些應該注意的編碼規范

一、規范存在的意義
應用編碼規范對於軟體本身和軟體開發人員而言尤為重要，有以下幾個原因：
1、好的編碼規范可以盡可能的減少一個軟體的維護成本 , 並且幾乎沒有任何一個軟體，在其整個生命周期中，均由最初的開發人員來維護；
2、好的編碼規范可以改善軟體的可讀性，可以讓開發人員盡快而徹底地理解新的代碼；
3、好的編碼規范可以最大限度的提高團隊開發的合作效率；
4、長期的規范性編碼還可以讓開發人員養成好的編碼習慣，甚至鍛煉出更加嚴謹的思維；
二、命名規范
1、一般概念
1、盡量使用完整的英文描述符
2、採用適用於相關領域的術語
3、採用大小寫混合使名字可讀
4、盡量少用縮寫，但如果用了，必須符合整個工程中的統一定義
5、避免使用長的名字（小於 15 個字母為正常選擇）
6、避免使用類似的名字，或者僅僅是大小寫不同的名字
7、避免使用下劃線（除靜態常量等）
2、標識符類型說明
1、包（ Package ）的命名
Package 的名字應該採用完整的英文描述符，都是由一個小寫單片語成。並且包名的前綴總是一個頂級域名，
通常是 com、e、gov、mil、net、org 等；
如： com.yjhmily.test
2、類（ Class ）的命名
類名應該是個一名詞，採用大小寫混合的方式，每個單詞的首字母大寫。盡量保證類名簡潔而富於描述。
使用完整單詞，避免縮寫詞 ( 除非工程內有統一縮寫規范或該縮寫詞被更廣泛使用，像 URL ， HTML)
如： FileDescription
3、介面（ Interface ）的命名
基本與 Class 的命名規范類似。在滿足 Classd 命名規則的基礎之上，保證開頭第一個字母為 」I」，
便於與普通的 Class區別開。其實現類名稱取介面名的第二個字母到最後，且滿足類名的命名規范；
如： IMenuEngine
4、枚舉（ Enum ）的命名
基本與 Class 的命名規范類似。在滿足 Classd 命名規則的基礎之上，保證開頭第一個字母為 」E」 ，
便於與普通的 Class區別開。
如： EUserRole
5、異常（ Exception ）的命名
異常（ Exception ） 通常採用字母 e 表示異常，對於自定義的異常類，其後綴必須為 Exception
如： BusinessException
6、方法（ Method ）的命名
方法名是一個動詞，採用大小寫混合的方式，第一個單詞的首字母小寫，其後單詞的首字母大寫。
方法名盡可能的描述出該方法的動作行為。返回類型為 Boolean 值的方法一般由「 is 」或「 has 」來開頭
如： getCurrentUser() 、 addUser() 、 hasAuthority()
7、參數（ Param ）的命名
第一個單詞的首字母小寫，其後單詞的首字母大寫。參數量名不允許以下劃線或美元符號開頭，
雖然這在語法上是允許的。參數名應簡短且富於描述。
如： public UserContext getLoginUser(String loginName);
8、常量欄位 （ Constants ）的命名
靜態常量欄位（ static final ） 全部採用大寫字母，單詞之間用下劃線分隔；
如： public static final Long FEEDBACK;
public static Long USER_STATUS;
三、注釋規范
一個很好的可遵循的有關注釋的經驗法則是：
問問你自己，你如果從未見過這段代碼，要在合理的時間內有效地明白這段代碼，你需要一些什麼信息？？？
1、一般概念
1、注釋應該增加代碼的清晰度
2、保持注釋的簡潔
3、在寫代碼之前或同時寫注釋
4、注釋出為什麼做了一些事，而不僅僅是做了什麼
2、注釋哪些部分
1、Java 文件：必須寫明版權信息以及該文件的創建時間和作者；
2、類：類的目的、即類所完成的功能，以及該類創建的時間和作者名稱；多人一次編輯或修改同一個類時，
應在作者名稱處出現多人的名稱；
3、介面： 在滿足類注釋的基礎之上，介面注釋應該包含設置介面的目的、它應如何被使用以及如何不被使用。
在介面注釋清楚的前提下對應的實現類可以不加註釋；
4、方法注釋： 對於設置 (Set 方法 ) 與獲取 (Get 方法 ) 成員的方法，在成員變數已有說明的情況下，
可以不加註釋；普通成員方法要求說明完成什麼功能，參數含義是什麼且返回值什麼；另外方法的創建
時間必須注釋清楚，為將來的維護和閱讀提供寶貴線索；
5、方法內部注釋： 控制結構，代碼做了些什麼以及為什麼這樣做，處理順序等，特別是復雜的邏輯處理部分，
要盡可能的給出詳細的注釋；
6、參數： 參數含義、及其它任何約束或前提條件；
7、屬性： 欄位描述；
8、局部 ( 中間 ) 變數： 無特別意義的情況下不加註釋；
3、注釋格式
遵循工程規定的統一注釋格式，一般情況下會以 codetemplates.xml 格式的文件導入 IDE(Eclipse)
或者用Eclipse默認的；
四、代碼格式規范
遵循工程規定的統一代碼格式，一般情況下直接使用 IDE(Eclipse) 自帶的默認代碼格式對代碼進行格式化；
五、其他規范
jsP 文件命名
採用完整的英文描述說明 JSP 所完成的功能，盡可能包括一個生動的動詞，第一個字母小寫，
如： viewMessage.jsp 、editUser.jsp 等。
六、工程特有命名規范
1、持久層
1、 Hibernate 映射文件及實體
與資料庫表名稱完全對應；
如： Advertisement.hbm.xml 、 Advertisement.java
2、數據訪問 DAO
DAO 介面和實現類名稱必須完全符合正常介面和實現類的命名規則，且最後以 」DAO」 結尾
DAO 內的數據訪問方法必須足夠抽象的描述出對資料庫的基本 CRUD 操作；
如： ICrossAdDAO( 介面 ) 、 CrossAdDAO( 實現類 )
3、各種操作資料庫的 HQL 配置文件
HQL 文件的個數原則上與系統的 Services 層的服務個數相等，且以服務名稱命名 HQL 文件；
如： resource.hbm.xml
2、服務層
1、服務介面和實現
服務介面和實現類必須完全符合正常介面和實現類的命名規則；以工程定義的服務名為主體，
並統一以 」Serv」 結尾
如： IResourceServ( 服務介面 ) 、 ResourceServ( 介面實現類 )
2、服務介面方法
方法名是一個動詞，採用大小寫混合的方式，第一個單詞的首字母小寫，其後單詞的首字母大寫。
方法名盡可能的描述出該方法的動作行為。
返回類型為 Boolean 值：用「 is 」或「 has 」來開頭
得到某數據： get+ 數據描述名詞復數 + 數據類型；
得到所有數據： get+All+ 數據描述名詞復數 + 數據類型；
通過 XXX 得到 / 查詢某數據： get/query+ 數據描述名詞復數 + 數據類型 +By+ 條件；
添加某數據： save/add+ 數據描述名詞 ()
更新某數據： save/update+ 數據描述名詞；
刪除某數據： delete/remove+ 數據描述名詞；
3、業務對象
業務名稱 +BO
4、查詢參數對象
凡是繼承 Abst***QuerySpec 的查詢參數類全部滿足以下規則：
Query+ 所要查詢的數據描述名詞 +Spec
作為參數傳入時，參數名必須為：所要查詢的數據描述名詞 +Spec
如： QueryProgramSpec
3、MVC 層
1、Action 控制層
Action 類名：功能模塊名稱 +Action ；
Actoin 方法名稱盡可能的描述出頁面遷移的去向
如： LoginAction( 登錄用 action) ， toWelcome( 轉向歡迎頁的 action 方法 )
2、資源文件
系統全局資源文件： globalMessages_+ 字元編碼類型 +.properties
功能模塊內部的資源文件： package.properties
4、Spring 配置文件
1、Action 相關配置文件
文件目錄： WebRoot/WEB-INF/spring/action/ 功能模塊名稱 +_ApplicationContext.xml
2、Services 相關配置文件
文件目錄： WebRoot/WEB-INF/spring/services/Services_ApplicationContext.xml
3、全局性配置文件
文件目錄： WebRoot/WEB-INF/spring/工程名+_ApplicationContext.xml
5、JSP 文件
採用完整的英文描述說明 JSP 所完成的功能，盡可能包括一個生動的動詞，第一個字母小寫，
如： viewMessage.jsp 、editUser.jsp 等。