資訊專欄INFORMATION COLUMN
摘要：努力避免硬編碼。一個類的總體行數盡量控制在行左右不超過一千行。函數注釋函數注釋采用，在每個函數或者過程的前面要有必要的注釋信息，包括函數或過程名稱功能描述輸入輸出及返回值說明調用關系及被調用關系說明等。
前言
推薦Google的Java編碼規范英文版：
http://google-styleguide.googlecode.com/svn/trunk/javaguide.html
雖然這篇文章的英文很簡單，但是最近發現有人翻譯了這篇文章，所以專門推薦一下：
http://hawstein.com/posts/google-java-style.html
正文一、命名規范
已經被使用的常量，不要重新定義
約定俗成的常量含義，不要重新定義。
努力避免硬編碼。
每個模塊，建議有獨立的常量類。
方法名都以lowerCamelCase風格編寫
類名都以UpperCamelCase風格編寫
參數名以lowerCamelCase風格編寫
局部變量名以lowerCamelCase風格編寫，比起其它類型的名稱，局部變量名可以有更為寬松的縮寫。
雖然縮寫更寬松，但還是要避免用單字符進行命名，除了臨時變量和循環變量。
即使局部變量是final和不可改變的，也不應該把它示為常量，自然也不能用常量的規則去命名它。
二、函數／方法
public 函數(方法)，對象參數 必須要處理參數為null的情況，
private 函數，對象參數 可以不用處理參數為null的情況(依情況而定)
方法名都以lowerCamelCase 開頭單詞小寫后面駝峰風格編寫
方法長度不超過50行
三、嵌套層級不要超過3層。
for，while，if ，switch 等。
方法中條件不成立直接return,不再向下執行
如：
public int xxx (String userId, String password, String email){
if(StringUtils.isEmpty(userId) || StringUtils.isEmpty(email)
||StringUtils.isEmpty(password)){
return null;
}
UserEntity ue = EntityProxy.OBJ.get(userId, UserEntity.class);
if(ue == null){
return null;
}
……...
}
避免前套層次過深，建議不超過三層
四、代碼結構
1垂直
以下情況需要使用一個空行：
類內連續的成員之間：字段，構造函數，方法，嵌套類，靜態初始化塊，實例初始化塊。
例外：兩個連續字段之間的空行是可選的，用于字段的空行主要用來對字段進行邏輯分組。
在函數體內，語句的邏輯分組間使用空行。
類內的第一個成員前或最后一個成員后的空行是可選的(既不鼓勵也不反對這樣做，視個人喜好而定)。
要滿足本文檔中其他節的空行要求。
多個連續的空行是允許的，但沒有必要這樣做(我們也不鼓勵這樣做)。
一個類的總體行數盡量控制在400行左右(不超過一千行)。
五、資源處理
EntityTransaction tranx = null;
try {
// 獲取數據庫事務
tranx = em.getTransaction();
// 開始事務過程
if(!tranx.isActive()){
tranx.begin();
}
// 保存實體
Query query = em.createNamedQuery(jpqlName);
if(params!=null && !params.isEmpty()){
params.forEach((k,v)->{
query.setParameter(k, v);
});
}
query.executeUpdate();
// 提交事務
tranx.commit();
} catch (Exception ex) {
// 記錄錯誤日志
DaoLog.LOG.error("刪除對象異常");
DaoLog.LOG.error(ex.getMessage(), ex);
if(tranx != null){
tranx.rollback();
}
return false;
}finally{
if(tranx !=null && tranx.isActive()){
tranx.commit();
}
em.close();//注意 用完一定要釋放
}
六、異常處理
比較底層的處理單元，建議拋出異常。
業務處理模塊，處理異常的同時，異常必須要加日志！最好有finally處理。
方法返回結果，不要使用異常方式。
七、相同的代碼快，不要到處出現或者重復出現！
相同代碼提取處理,讓代碼可重用。
八、注釋
1、源文件注釋
源文件注釋采用 /* …… /，在每個源文件的頭部要有必要的注釋信息，包括：文件名；文件編號；版本號；作者；創建時間；文件描述包括本文件歷史修改記錄等。中文注釋模版：
/**
文 件 名 :
CopyRright (c) 2015-xxxx:
文件編號：
創 建 人：
日 期：
修 改 人：
日 期：
描 述：
版 本 號：
*/
2、類（模塊）注釋：
類（模塊）注釋采用 /* …… /，在每個類（模塊）的頭部要有必要的注釋信息，包括：工程名；類（模塊）編號；命名空間；類可以運行的JDK版本；版本號；
作者；創建時間；類（模塊）功能描述（如功能、主要算法、內部各部分之間的關系、該類與其類的關系等，必要時還要有一些如特別的軟硬件要求等說明）；
主要函數或過程清單及本類（模塊）歷史修改記錄等。
3、接口注釋：
接口注釋采用 /* …… /，在滿足類注釋的基礎之上，接口注釋應該包含描述接口的目的、它應如何被使用以及如何不被使用，塊標記部分必須注明作者和版本。
在接口注釋清楚的前提下對應的實現類可以不加注釋。
4、構造函數注釋：
構造函數注釋采用 /* …… /，描述部分注明構造函數的作用，不一定有塊標記部分。
5、函數注釋：
函數注釋采用 /* ……/，在每個函數或者過程的前面要有必要的注釋信息，包括：函數或過程名稱；功能描述；
輸入、輸出及返回值說明；調用關系及被調用關系說明等。函數注釋里面可以不出現版本號（@version）。
6、方法注釋：
方法注釋采用 /* …… /，普通成員方法要求說明完成什么功能，參數含義是什么且返回值什么；另外方法的創建時間必須注釋清楚，為將來的維護和閱讀提供寶貴線索。
7、方法內部注釋：
控制結構，代碼做了些什么以及為什么這樣做，處理順序等，特別是復雜的邏輯處理部分，要盡可能的給出詳細的注釋。
8、全局變量注釋：
要有較詳細的注釋，包括對其功能、取值范圍、哪些函數或者過程存取以及存取時注意事項等的說明。
9、局部（中間）變量注釋：
主要變量必須有注釋，無特別意義的情況下可以不加注釋。
10、實參/參數注釋：
參數含義、及其它任何約束或前提條件。
十、if else 條件含義要明確
如：
if (isOk) { //isOK 如何
return Response.status(200).entity(resp.getData()).build();
} else {
return Response.status(200).entity(resp.getErrorInfo()).build();
}
十一、邏輯控制，不要瀑布流！
盡量把條件不滿足的情況寫在某個邏輯塊的前面(比如方法的最前面)，讓不滿足條件的情況快速失敗，讓代碼整理結構清晰，可讀。
十二、巧用構造函數構造者builder模式：
