1..7 控制語句

1.強制:在一個 switch 塊內,每個 case 要麼通過 break / return 等來終止,要麼註釋說明程序將繼續執行到哪一個 case 爲止;在一個 switch 塊內,都必須包含一個 default 語句並且放在最後,即使它什麼代碼也沒有。

2.強制:在 if / else / for / while / do 語句中,必須使用大括號。即使只有一行代碼,也應避免採用單行的編碼方式:

        if(condition) statements;.

3.強制:在高併發場景中,避免使用“等於”判斷作爲中斷或退出的條件。

說明:

        如果併發控制沒有處理好,容易產生等值判斷直接被“擊穿”的情況,應使用大於或小於的區間判斷條件來代替。

反例:

        判斷剩餘獎品數量等於 0 時,終止發放獎品,但因爲併發處理錯誤導致獎品數量瞬間變成了複數,這樣的話,活動無法終止。

4.推薦:在表達異常的分只是,儘量少用 if-else 方式,這種方式可以改寫成:

if(condition){

    ...

    return obj;

}

// 接着寫 else 的業務邏輯代碼

說明:

        如果不得不適用 if () ... else if () ... else ... 方式表達邏輯, 強制:避免後期代碼維護困難,請勿超過 3 層。

正例:

        超過 3 層的 if-else 邏輯判斷代碼可以使用衛語句、策略模式、狀態模式等來體現,其中衛語句實例如下:

public void today(){

    if (isBusy()){

        System.out.println("change time.");

        return ;

    }

    if(ifFree()){

        System.out.println("go to travel.");

        return ;

    }

    System.out.println("stay to home to learn Alibaba Java Coding Guidelines.");

    return ;

}

說明:

        衛語句就是把複雜條件表達式拆分成多個條件表達式,條件爲真時,立刻從方法體重返回給調用方。

5.推薦:除常用方法(如 getXxx / isXxx)外,不要再條件判斷中執行其他複雜的語句,可將複雜邏輯判斷的結果賦值給一個有意義的布爾變量名,以提高可讀性。

說明:

        很多 if 語句內的邏輯表達式相當複雜,與、或、取反混合運算,理解成本非常高。如果賦值一個非常好理解的布爾變量,則是件令人爽心悅目的事情。

正例:

        // 僞代碼如下:

        final boolean existed = (file.open(name, "w") != null) && (...) || (...) );

        if(existed){

            ...

        }

反例:

        if((file.open(name,"w") != null) && (...) || (...)){

                ...

        }

6.推薦:循環體中的語句要考量性能。以下操作儘量移至循環體外處理,如定義對象或變量、獲取數據庫連接,避免進行不必要的 try-catch 操作。

說明:   

        對循環體內的 try-catch 操作,需要思考是否可以移至循環體外。

7.推薦:避免採用取反邏輯運算符。

說明:

        取反邏輯不利於快速理解,並且取反邏輯寫法必然存在對應的正向邏輯寫法。

正例:

        使用 if (x < 628) 來表達 x 小於 628 。

反例:

        使用 if(!(x >= 628)) 來表達 x 小於 628。

8.推薦:接口入參保護,這種場景常見的是用作批量操作的接口。

9.參考:下列情形,需要進行參數校驗:

  1. 調用頻次的的方法。
  2. 執行時間開銷很大的方法。此情形中,參數校驗時間幾乎可以忽略不計,但如果因爲參數錯誤導致中間執行回退,或者錯誤,那得不償失。
  3. 需要極高的穩定性和可用性的方法。
  4. 對外提供的開發接口,不管是否爲 RPC / API / HTTP 接口。
  5. 敏感權限入口。

10.參考:下列情形,不需要進行參數校驗:

  1. 極有可能被循環調用的方法。但在方法裏必須註明外部參數檢查要求。
  2. 底層調用頻度比較高的方法。畢竟是像純淨水過濾的最後一道,參數錯誤不太可能到底層才暴露問題。一般 DAO 層與 Service 層在同一個應用中,並部署在同一個服務器中,所以 DAO 的參數校驗可以忽略。
  3. 被聲明成 private 只會自己代碼所調用的方法,如果能夠確定調用方法的代碼傳入參數已經做過檢查或者肯定不會有問題,可以不檢驗參數。




















發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章