使用的 “如果/ 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语句}”

回答

相关问题