1.在switch塊內，每個case通過break/return等終止，或者說明繼續執行到那個case爲止。每個switch塊內，必須包含一個default語句且放在最後。即使什麼沒有。
2.if/else/for/while/do語句中必須使用大括號，即使一行代碼
3.表達異常的分支時，少用if-else
可以使用
if(condition){
.. return obj;
}
如果非要使用，勿超過3層。超過三層可以使用衛語句、策略模式、狀態模式等實現
4.除常用方法（getXXX isXXX）等外，不要在條件判斷中執行其他複雜語句，提高可讀性
5.循環體中語句要衡量性能，儘量移至循環體外處理（如定義對象、變量、獲取數據庫連接，進行不必要的try-catch操作）
6.做批量操作的接口，接口入參保護。
7.參數校驗
1）調用頻率低的方法
2）執行時間開銷很大的方法
3）需要極高穩定性和可用性方法
4）對外提供的開放接口，（如RPC/API/HTTP接口）
5）敏感權限入口
8.不需要參數校驗
1）可能被循環調用的方法，方法說明外部參數檢查要求
2）底層調用頻度高的方法 例如DAO參數校驗
3）聲明private方法，只會被自己調用的方法
補充--引自http://www.cnblogs.com/huahua035/p/6905504.html
工作中很少提到“入參保護”這個詞，更多的是“參數校驗”的說法；談下個人對接口入參保護的理解：
1、接口入參保護，“保護”的是服務端應用，即接口提供方，最常見的做法就是校驗入參的有效值範圍和設置批量操作白名單；比如，接口入參中包含日期時，校驗日期必須在N天範圍內，或者請求返回的記錄總數必須在X條以內（比如10W條，否則縮小請求查詢的記錄範圍），或者請求返回的記錄必須分頁查詢返回；
開發手冊中，尤其提到的場景就是批量操作，因爲批量操作非常耗時耗資源（服務端），批量操作的批量數應該有上限，而不是無限的。假如客戶端請求一次批量操作10W筆轉賬訂單，服務器應該果斷拒絕，很不是很SB的忠實執行，會對服務端造成嚴重影響的批量請求，服務器端應做好保護性編程，必要時應直接失敗，並在Result中返回明確的errorCode和errorMsg;而且，對應批量操作，實際應用中還會配置批量操作白名單！
2、入參保護，一般都是通過衛語句實現：if（請求記錄>10000條） return；直接返回。