是否有必要在每个if条件中写出其他部分？

问题描述 投票：13回答：10

我问的问题可能会被关闭，但我只是想知道是否有必要写下每个if条件的一部分。我的一位高级程序员告诉我“你应该把其他部分写入每一个条件”。假设我们没有条件写入else部分那么我们该怎么办？我假设这里将进行健康的讨论....

programming-languages concept
10个回答
16
投票

这是一个可怕的想法。您最终获得了表单的代​​码：

if (something) {
    doSomething();
} else {
}

任何人都可以认为没有else更具可读性或可维护性超出我的范围。这听起来像是由那些手上有太多空闲时间的人组成的规则之一。让他们尽可能快地解雇，或者至少平静而安静地离开:-)

0
投票

我知道我迟到了，但我对此做了很多思考，并想分享我的结果。

在关键代码中，每个分支都必须考虑到。写一个其他的没有必要，但留下一个其他不必要的标记和原因。这将有助于审稿人。注意：

//negatives should be fixed
if(a < 0) {
    a+=m;
}
//else value is positive
8
投票

不，你当然不必 - 至少在大多数语言中。 （你没有指明;很可能有一种语言可以强制执行这个。）这是一个我肯定不会这样做的例子：

public void DoSomething(string text)
{
    if (text == null)
    {
        throw new ArgumentNullException("text");
    }
    // Do stuff
}

现在你可以将方法的主要工作放在这里的“else”子句中 - 但它会不必要地增加嵌套。添加一些条件，整个事情变得难以理解。

根据我的经验，这种“早出”的模式相当普遍 - 并且适用于返回值和异常。我知道有些人赞成从一个方法中获得单个返回点，但是在我使用的语言中（Java，C＃），这通常会导致代码可读性更低，嵌套更深。

现在，有一种情况是辩论的范围更广，而且这两个分支都是终端，但它们都不是有效的捷径：

public int DoSomething()
{
    // Do some work
    if (conditionBasedOnPreviousWork)
    {
        log.Info("Condition met; returning discount");
        return discount;
    }
    else
    {
        log.Info("Condition not met; returning original price");
        return originalPrice;
    }
}

（请注意，我故意给两个分支做更多的工作而不仅仅是返回 - 否则条件语句是合适的。）

如果没有“其他”，这会更具可读性吗？这真的是个人选择的问题，我不会声称我总是一致的。两个分支同等地缩进使得它们在某种程度上具有相同的权重 - 并且可能鼓励稍后通过反转条件进行重构的可能性......而如果我们刚刚进入“返回原始价格”，则重构将其放入if块中乍一看，将折扣案移出一个if块就不那么明显了。

4
投票

危险！威尔罗宾逊，危险！

http://en.wikipedia.org/wiki/Cargo_cult_programming

是否包含空的else { }块会以某种方式提高代码的质量，可读性或稳健性？我想不是。

4
投票

在Java和C等命令式语言中，if - else是一个语句，不返回值。所以你可以愉快地只写if部分并继续。而且我认为这是更好的做法，而不是在每个else之后添加空的ifs。

但是在像Haskell和Clojure这样的函数式语言中，if是一个表达式，它必须返回一个值。所以必须用else成功。但是，仍有一些情况下您可能不需要else部分。对于这种情况，Clojure有一个when宏，包裹if - else返回nil部分的else并避免写它。

(when (met? somecondition)
  (dosomething))
1
投票

纯粹从语义的角度来看这个 - 我想不出一个单独的案例，其中没有一个隐含的其他if。

如果在我到达墙壁之前车没有停下来我会崩溃，否则我不会崩溃。

抛开语义：

这个问题的答案取决于环境，以及错误的结果。

商业代码？做你的编码标准所说的。 恕我直言，你会发现拼写它，虽然最初似乎太多的工作，从你现在重新访问该代码10年后将变得非常宝贵。但是，如果你错过了一个重要的“反条件”，它肯定不会是世界末日。

但是：安全性，安全性或生命关键代码？那是一个不同的故事。

在这种情况下，你想做两件事。 第一：你想要证明没有错误，而不是测试一个错误。这需要对任何模块的进入持悲观态度。在你证明它是正确的之前，你认为一切都是错的。 第二：生命危急：你永远不想伤害病人：

bool everyThingIsSafe = true;
if(darnThereIsAProblem())
{
   reportToUserEndOfWorld();
}
return everyThingIsSafe;

哎呀。我忘了将everyThingIsSafe设置为false。 调用此snippit的例程现在被骗了。如果我将evertThingIsSafe初始化为false - 我总是安全的，但现在我需要else子句来指示没有错误。 是的，我本来可以把它改成一个积极的测试 - 但后来我需要别的来处理错误。 是的，我可以分配everyThingIsSafe（）立即返回支票。然后测试该标志以报告问题。隐含的其他，为什么不明确？ 严格地说，这代表隐含的其他是合理的。 对于FDA /安全审核员，可能不是。 如果它是明确的，可以指向测试，它的其他，并且我清楚地处理了这两个条件。

我已经为医疗设备编码了25年。在这种情况下，你想要else，你想要在这种情况下的默认值，它们永远不会是空的。你想知道到底会发生什么，或者尽可能地知道。因为忽视一个条件可能会杀死某人。

查看Therac-25。 8人重伤。 3死了。

0
投票

有时候没有其他部分....而且包括一个空的只是使代码不太可读imho。

0
投票

不，你不必......

另外，我认为这对可读性来说不是一个好主意，因为你会有很多空的else块。哪个不太好看。

0
投票

这纯粹是风格和清晰度的问题。很容易想象，如果陈述，特别是简单的陈述，其他的话将是多余的。但是当你有一个更复杂的条件，或许可以处理许多不同的情况时，通常可以澄清明确声明否则，什么都不应该做。在这些情况下，我会在其他空的其他地方留下// do nothing评论，以清楚该空间是故意留空的。

0
投票

不，但我个人选择总是包括封装括号以避免

if (someCondition)
    bar();
    notbar();  //won't be run conditionally, though it looks like it might

foo();

我会写的

 if (someCondition){
        bar();
        notbar();  //will be run
 }
 foo();
最新问题
© www.soinside.com 2019 - 2024. All rights reserved.