## 七、控制語句 1. 【**強制**】在一個 switch 塊內,每個 case 要么通過 break/return 等來終止,要么注釋( //fall through to **** )說明程 序將繼續執行到哪一個 case 為止;在一個 switch 塊內,都必須包含一個 default 語句并且 放在最后,即使它什么代碼也沒有。 * * * * * 2. 【**強制**】在 if/else/for/while/do 語句中必須使用大括號,即使只有一行代碼,避免使用 下面的形式: if (condition) statements; * * * * * 3. 【推薦】推薦盡量少用 else, if-else 的方式可以改寫成: if (condition) { ... return obj; } // 接著寫 else 的業務邏輯代碼; 說明:如果非得使用 if()...else if()...else... 方式表達邏輯,【強制】請勿超過3層, 超過請使用狀態設計模式。 正例： 邏輯上超過 3 層的 if-else 代碼可以使用衛語句(Guard Clause),或者狀態模式來實現。 一般而言條件表達式有不同的用途。如果多條分支都是正常行為，就應該使用形如if…..else…..的條件表達式；如果某個條件極其罕見，就應該單獨檢查該條件，并在該條件為真時立刻從函數中返回或拋出異常。這樣的單獨檢查常常被稱為“衛語句”。 具體詳情參見：http://blog.csdn.net/jw903/article/details/45506777 “每個函數只能有一個入口和一個出口”的觀念，根深蒂固于某些程序員的腦海里。現今的編程語言都會強制保證每個函數只有一個入口，至于“單一出口”規則，其實不是那么過于強求。**保持代碼清晰才是最關鍵的**：如果單一出口能使這個函數更清晰易讀，那么就使用單一出口；否則就不必這么做。 * * * * * 4. 【推薦】除常用方法(如 getXxx/isXxx)等外,不要在條件判斷中執行其它復雜的語句,將復 雜邏輯判斷的結果賦值給一個有意義的布爾變量名,以提高可讀性。 >說明:很多 if 語句內的邏輯相當復雜,閱讀者需要分析條件表達式的最終結果,才能明確什么 樣的條件執行什么樣的語句,那么,如果閱讀者分析邏輯表達式錯誤呢? 正例: //偽代碼如下 boolean existed = (file.open(fileName, "w") != null) && (...) || (...); if (existed) { ... } 反例: if ((file.open(fileName, "w") != null) && (...) || (...)) { ... } * * * * * 5. 【推薦】循環體中的語句要考量性能,以下操作盡量移至循環體外處理,如定義對象、變量、獲取數據庫連接,進行不必要的 try-catch 操作(這個 try-catch 是否可以移至循環體外)。 * * * * * 6. 【推薦】接口入參保護,這種場景常見的是用于做批量操作的接口。 * * * * * 7. 【參考】方法中需要進行參數校驗的場景: 1)、 調用頻次低的方法。 2)、執行時間開銷很大的方法,參數校驗時間幾乎可以忽略不計,但如果因為參數錯誤導致中間執行回退,或者錯誤,那得不償失。 3)、需要極高穩定性和可用性的方法。 4)、對外提供的開放接口,不管是RPC/API/HTTP接口。 5)、敏感權限入口。 * * * * * 8. 【參考】方法中不需要參數校驗的場景: 1)、極有可能被循環調用的方法,不建議對參數進行校驗。但在方法說明里必須注明外部參數檢查要求。 2)、底層的方法調用頻度都比較高,一般不校驗。畢竟是像純凈水過濾的最后一道,參數錯誤不太可能到底層才會暴露問題。一般 DAO 層與 Service 層都在同一個應用中,部署在同一 臺服務器中,所以 DAO 的參數校驗,可以省略。 3)、被聲明成private只會被自己代碼所調用的方法,如果能夠確定調用方法的代碼傳入參 數已經做過檢查或者肯定不會有問題,此時可以不校驗參數。