17

我问的问题可能已经结束，但我只想知道是否有必要在每个 if 条件中编写 else 部分。我的一位高级程序员对我说“你应该在每个 if 条件中写 else 部分”。假设我们没有在 else 部分写的条件，那我们该怎么办？我认为这里将进行健康的讨论....

4

12 回答 12

17

这是一个可怕的想法。您最终得到以下形式的代码：

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

怎么会有人认为根本没有 a 更具可读性或可维护性，这else超出了我的范围。这听起来像是那些有太多空闲时间的人制定的规则之一。尽快让他们被解雇，或者至少平静而安静地离开:-)

于 2010-08-03T06:03:33.010 回答
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 块显然不太正确。

于 2010-08-03T06:04:47.783 回答
5

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

然而，在 Haskell 和 Clojure 等函数式语言中，if是一个表达式，它必须返回一个值。所以它必须以else. 但是，仍然存在您可能不需要else部分的情况。对于这种情况，Clojure 有一个when宏，它可以在节if - else中返回并避免编写它。nilelse

(when (met? somecondition)
  (dosomething))
于 2010-08-03T06:23:48.247 回答
4

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

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

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

于 2010-08-03T06:03:31.413 回答
1

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

在关键代码中，必须考虑每个分支。写一个else不是必须的，但要留下一个标记else是没有必要的以及为什么。这将有助于审稿人。观察：

//negatives should be fixed
if(a < 0) {
    a+=m;
}
//else value is positive
于 2015-02-10T08:59:23.947 回答
1

纯粹从语义的角度来看这个——我想不出每个 if 都没有隐含 else 的单一情况。

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

除了语义：

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

业务代码？做你的编码标准所说的。
恕我直言，您会发现，虽然最初看起来工作量太大，但当您重新访问该代码时，将在 10 年后变得非常宝贵。但是，如果你错过了一个重要的“反条件”，那肯定不会是世界末日。

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

在这种情况下，你想做两件事。
第一：不是测试故障，而是要证明没有故障。这需要对进入任何模块持悲观态度。你假设一切都是错误的，直到你证明它是正确的。
第二：在生命中至关重要：你永远不想伤害病人。：

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

哎呀。我忘记将everyThingIsSafe 设置为假。
调用此代码段的例程现在被骗了。如果我将 evertThingIsSafe 初始化为 false - 我总是安全的，但现在我需要 else 子句来表明没有错误。
是的，我本可以将其更改为正面测试 - 但是我需要 else 来处理故障。
是的，我本可以为everyThingIsSafe() 分配支票的立即返还。然后测试标志以报告问题。一个隐含的 else，为什么不显式呢？
严格来说，this所代表的隐含的else是合理的。
对于 FDA/安全审核员，也许不是。
如果它是明确的，可以指向测试，它的其他，并且我清楚地处理了这两个条件。

我已经为医疗设备编码 25 年了。在这种情况下，您需要 else，您需要 case 中的默认值，并且它们永远不会为空。你想确切地知道会发生什么，或者尽可能接近。因为忽略一个条件可能会杀死一个人。

查找 Therac-25。8人重伤。3死。

于 2014-01-24T17:40:31.067 回答
1

不，不需要为语句编写else部分。if

事实上，大多数开发人员更喜欢并建议避免else阻塞。

那是

而不是写

if (number >= 18) {
    let allow_user = true;
} else {
    let allow_user = false;
}

大多数开发人员更喜欢：

let allow_user = false;
if (number >= 18) {
    let allow_user = true;
}
于 2019-08-22T11:08:16.797 回答
0

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

于 2010-08-03T06:05:37.703 回答
0

不，你不必..

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

于 2010-08-03T06:00:27.937 回答
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();
于 2010-08-03T06:04:19.657 回答
0

有时没有其他部分......并且包括一个空的部分只会使代码不那么可读恕我直言。

于 2010-08-03T06:04:57.213 回答
0 
def in_num(num):
    if num % 3 == 0:
        print("fizz")
    if num % 5 == 0:
        print("buzz")
    if (num % 3 !=0) and (num % 5 !=0):
        print(num)

请参阅此代码中的 else 语句是不必要的。

于 2022-01-07T07:26:45.520 回答