反例：public int f(){ returnInteger物件}，如果為null，自動解箱拋NPE。

2）資料庫的查詢結果可能為null。

3）集合裡的元素即使isNotEmpty，取出的資料元素也可能為null。

4）遠端呼叫返回物件，一律要求進行NPE判斷。

5）對於Session中獲取的資料，建議NPE檢查，避免空指標。

6）級聯呼叫obj.getA().getB().getC()；一連串呼叫，易產生NPE。

11.【推薦】在程式碼中使用“拋異常”還是“返回錯誤碼”，對於公司外的http/api開放介面必須使用“錯誤碼”；而應用內部推薦異常丟擲；跨應用間RPC呼叫優先考慮使用Result

說明：關於RPC方法返回方式使用Result方式的理由：

1）使用拋異常返回方式，呼叫方如果沒有捕獲到就會產生執行時錯誤。

2）如果不加棧資訊，只是new自定義異常，加入自己的理解的error message，對於呼叫端解決問題的幫助不會太多。如果加了棧資訊，在頻繁調用出錯的情況下，資料序列化和傳輸的效能損耗也是問題。

12.【推薦】定義時區分unchecked/checked異常，避免直接使用RuntimeException丟擲，更不允許丟擲Exception或者Throwable，應使用有業務含義的自定義異常。推薦業界已定義過的自定義異常，如：

13.【參考】避免出現重複的程式碼（Don’t RepeatYourself），即DRY原則。

說明：隨意複製和貼上程式碼，必然會導致程式碼的重複，在以後需要修改時，需要修改所有的副本，容易遺漏。必要時抽取共性方法，或者抽象公共類，甚至是共用模組。

正例：一個類中有多個public方法，都需要進行數行相同的引數校驗操作，這個時候請抽取：

private boolean checkParam(DTO dto){...}

(二) 日誌規約

1.【強制】應用中不可直接使用日誌系統（Log4j、Logback）中的API，而應依賴使用日誌框架

SLF4J中的API，使用門面模式的日誌框架，有利於維護和各個類的日誌處理方式統一。

import org.slf4j.Logger;

import org.slf4j.LoggerFactory;

private static final Loggerlogger = LoggerFactory.getLogger(Abc.class);

2. 【強制】日誌檔案推薦至少儲存15天，因為有些異常具備以“周”為頻次發生的特點。

3. 【強制】應用中的擴充套件日誌（如打點、臨時監控、訪問日誌等）命名方式：appName_logType_logName.log。logType:日誌型別，推薦分類有stats/desc/monitor/visit

等；logName:日誌描述。這種命名的好處：通過檔名就可知道日誌檔案屬於什麼應用，什麼