使用的「如果/ ELSEIF /其他」與「的if/else {if/else語句}」

我發現自己非常普遍使用這樣的模式：使用的「如果/ ELSEIF /其他」與「的if/else {if/else語句}」

if (a > b) { 
     foo(); 
} 
elseif (c > d) { 
     bar(); 
} 
else { 
     baz(); 
}

在這裏點是第二個條件是除非您仔細地遵循程序邏輯，否則不會明顯與第一個連接。這是非常糟糕的事情嗎？如果將上述短語描述爲：

if (a > b) { 
     foo(); 
} 
else { 
     if (c > d) { 
      bar(); 
     } 
     else { 
      baz(); 
     } 
}

是否出於可維護性原因？有沒有更好的模式，我完全錯過了？「不明顯連接」位似乎是我的代碼中更常見的錯誤來源之一。

來源

2011-04-01 Leland Thorpe

我認爲第一個是絕對可取的。唯一一次我使用第二種方法是將代碼放在內部的if/else中的不是。

當我看到別的時候，我立即尋找if。所以我想說它顯然是連接的。

來源

2011-04-01 20:06:03

我避免使用第二種方法，因爲它會導致大條件的縮進。

來源

2011-04-01 20:16:13

這並不重要。

我喜歡漏的划艇*模式：

if (a > b) 
{ 
    foo(); 
    return; 
} 

if (c > d) 
{ 
    bar(); 
    return; 
} 
baz();

這甚至更好，當你正在返回的東西：

if (a > b) 
    return foo(); 

if (c > d) 
    return bar(); 

return baz();

_{_{*保釋年初，保釋快速}}

來源

2011-04-01 20:18:17 Will

+1漏的划艇FTW – Kurru 2011-04-02 11:54:44

感嘆，這是一個地方，我從很多不同（如果不是大多數）編碼器：我真的喜歡只有一個從函數退出點。我確信這種模式有很多好的理由，但我喜歡最後得到一個回報的清潔度，理想的情況是在評論之前說「到現在爲止，以下是真的：」。看起來我應該去這個網站上的某個地方閱讀。 – 2011-04-04 13:29:20

@LelandThorpe：嚴格遵守SESE導致[箭頭反模式]（http://lostechies.com/chrismissal/2009/05/27/anti-patterns-and-worst-practices-the-arrowhead-anti-模式/），這可以大大提高[圈複雜度]（http：//en.wikipedia。org/wiki/Cyclomatic_complexity）的代碼（越複雜，越難以維護）。國際海事組織（不謙虛），如果發現自己超過三個深度括號，他們做錯了什麼。嚴格遵守美學（這是所有SESE是，恕我直言）導致不良的編碼做法。 – Will 2011-04-04 13:42:11

我肯定會使用第一個，因爲它比第二個更可讀。

第二個選項將迫使讀者記住哪些條件必須是真實的，以便在每個時刻讀取的位置以及第三或第四個嵌套的嵌套位置，如果這變得非常煩人並且非常脆弱並且邏輯上很難遵循。

來源

2011-04-01 20:27:27 CloudyMarble

我認爲這是一種代碼味道。這不是很明顯，你在這裏做什麼，或者你爲什麼這樣做。事實上，你認爲他們沒有明顯的聯繫，並且他們是錯誤的常見來源是告訴你不要這樣做。

重寫此代碼，以便您在這些條件上分支的原因很明確。理想情況下，您將能夠閱讀代碼並使其表達您的意圖和/或您的規格。

taller_than_wide = a > b; 
more_expensive_than_normal = c > d; 

if (taller_than_wide) { 
     foo(); 
} 
elseif (more_expensive_than_normal) { 
     bar(); 
} 
else { 
     baz(); 
}

來源

2011-07-12 04:55:49

使用的 「如果/ ELSEIF /其他」 與 「的if/else {if/else語句}」

回答

相關問題

使用的「如果/ ELSEIF /其他」與「的if/else {if/else語句}」