反转IF语句

因此，我已经编程了几年，最近又开始更多地使用ReSharper。ReSharper经常向我建议的一件事是“反转'if'语句以减少嵌套”。

假设我有以下代码：

foreach (someObject in someObjectList) 
{
    if(someObject != null) 
    {
        someOtherObject = someObject.SomeProperty;
    }
}

ReSharper建议我这样做：

foreach (someObject in someObjectList)
{
    if(someObject == null) continue;
    someOtherObject = someObject.SomeProperty;
}

看来，无论进行多少嵌套，ReSharper都会总是建议我反转IF。这个问题是我至少在某些情况下喜欢嵌套。对我来说，似乎更容易阅读和弄清某些地方的情况。并非总是如此，但有时我感到更舒适的嵌套。

我的问题是：除了个人喜好或可读性之外，还有其他减少嵌套的理由吗？是否存在性能差异或其他我可能不知道的东西？

这取决于。在您的示例中，具有非反向if语句不是问题，因为的主体if非常短。但是，通常您希望在主体增长时反转语句。

我们只是人类，很难一次掌握多件事情。

当一个语句的主体很大时，反转该语句不仅可以减少嵌套，而且还告诉开发人员他们可以忘记该语句上方的所有内容，而只关注其余部分。您很可能会使用反向语句尽快消除错误的值。一旦知道这些都不在游戏中，剩下的就是可以实际处理的值。

不要避免负面影响。即使CPU喜欢它们，人类也会像解析它们一样吮吸。

但是，尊重成语。我们人类是习惯性的动物，因此我们更喜欢穿着破旧的道路来开满杂草的道路。

foo != null可悲的是，它已成为一种习语。我几乎没有注意到这些单独的部分。我看了一下，然后想，“哦，现在可以安全点了foo”。

如果您想推翻那个（哦，有一天，请），您需要一个非常有力的理由。您需要使我的眼睛毫不费力地滑下来并立即理解它的东西。

但是，您给我们的是：

foreach (someObject in someObjectList)
{
    if(someObject == null) continue;
    someOtherObject = someObject.SomeProperty;
}

在结构上甚至都不一样！

foreach (someObject in someObjectList)
{
    if(someObject == null) continue;
    someOtherObject = someObject.SomeProperty;

    if(someGlobalObject == null) continue;
    someSideEffectObject = someGlobalObject.SomeProperty;
}

那不是我懒惰的大脑所期望的那样。我以为我可以继续添加独立代码，但我不能。这使我考虑了我现在不想考虑的事情。你打破了我的习惯，但没有给我更好的习惯。全部是因为您想保护我免受那消极的消极情绪的伤害，这是一个令人讨厌的小小的自我。

很抱歉，也许ReSharper在90％的时间里都建议这样做，但是在空检查中，我认为您发现了一个极端的情况，最好忽略它。工具根本不擅长教您什么是可读代码。问一个人。做同行评审。但是不要盲目地使用该工具。

关于中断是否比嵌套更糟糕是一个古老的争论。

人们似乎接受参数检查的尽早返回，但是在大部分方法中它都被拒绝了。

就个人而言，即使这意味着更多的嵌套，我也避免继续，中断，跳转等。但是在大多数情况下，您都可以避免两者。

foreach (someObject in someObjectList.where(i=>i != null))
{
    someOtherObject = someObject.SomeProperty;
}

显然，当您有许多层时，嵌套的确会使事情变得难以处理

foreach (someObject in someObjectList) 
{
    if(someObject != null) 
    {
        someOtherObject = someObject.SomeProperty;
        if(someObject.x > 5) 
        {
            x ++;
            if(someObject.y > 5) 
            {
                x ++;
            }
        }
    }
}

最糟糕的是

foreach (someObject in someObjectList) 
{
    if(someObject != null) 
    {
        someOtherObject = someObject.SomeProperty;
        if(someObject.x > 5) 
        {
            x ++;
            if(someObject.y > 5) 
            {
                x ++;
                return;
            }
            continue;
        }
        someObject.z --;
        if(myFunctionWithSideEffects(someObject) > 6) break;
    }
}

的问题continue在于，如果在代码中添加更多行，则逻辑会变得很复杂，并且可能包含错误。例如

foreach (someObject in someObjectList)
{
    if(someObject == null) continue;
    someOtherObject = someObject.SomeProperty;

    ...  imagine that there is some code here ...

    // added later by a Junior Developer
    doSomeOtherFunction(someObject);
}

你要拨打doSomeOtherFunction()的所有 someObject，或者只在非空？使用原始代码，您可以选择，而且更清晰。随着continue人们可能忘了：“哦，是的，回到那里，我们跳过空”，你甚至不必调用它的所有someObjects的选项，除非你把该呼叫在方法的开始可能是不可能的或不正确由于其他原因。

是的，很多嵌套很难看，而且可能造成混乱，但是在这种情况下，我将使用传统样式。

额外的问题： 为什么列表中以空开头？最好不要从头开始添加null，在这种情况下，处理逻辑要简单得多。

这个想法是早日回归。早return在一个循环变得早continue。

这个问题有很多好的答案：我应该早点从函数返回还是使用if语句？

请注意，虽然该问题是基于意见而关闭的，但430票以上赞成提前归还，〜50票是“取决于”，而8票反对早期归还。因此，有一个非常强烈的共识（这或者说我不好算，这是合理的）。

就个人而言，如果要使循环主体早日继续并且需要足够长的时间（3-4行），那么我倾向于将循环主体提取到一个函数中，在该函数中我使用早期返回而不是早期继续。

当满足您的方法的主要条件时，此技术对于验证前提条件很有用。

我们经常颠倒ifs我的工作，并雇用其他人。过去经常在审查PR时经常指出我的同事如何删除三个嵌套层！由于我们确实推出了ifs，因此发生的频率降低了。

这是一个可以推广的玩具示例

function foobar(x, y, z) {
    if (x > 0) {
        if (z != null && isGamma(y)) {
            // ~10 lines of code
            // return something
        }
        else {
           return y
        }
    }
    else {
      return y + z
    }
}

像这样的代码，在一种情况下（其余的只是返回值或小的语句块）很常见。将上面的内容重写为

function foobar(x, y, z) {
    if (x <=0) {
        return y + z
    }
    if (z == null || !isGamma(y) {
       return y
    }
    // ~ 10 lines of code
    // return something
}

在这里，我们的重要代码（不包括10行）在函数中没有三重缩进。如果您使用的是第一种样式，则很容易将长块重构为一种方法或允许缩进。这是节省的地方。在一个地方，这是微不足道的节省，但是在许多类的许多方法中，您无需生成额外的功能来使代码更简洁，而不必再进行多层次的丑陋处理压痕。

在回应OP的代码示例时，我确实同意那是一个急切的崩溃。特别是由于我使用的样式为1TB，因此反转会导致代码增大。

转载建议通常是有用的，但应始终进行严格评估。它寻找一些预定义的代码模式并提出转换建议，但是它不能考虑使代码对人类可读性更高的所有因素。

在所有其他条件相同的情况下，最好使用较少的嵌套，这就是ReSharper将建议减少嵌套的转换的原因。但是所有其他条件都不相等：在这种情况下，转换需要引入continue，这意味着生成的代码实际上更难遵循。

在某些情况下，一个交换嵌套的水平continue 可能确实是一种进步，但是这取决于有问题的代码，这是超越ReSharpers机械规则的理解的语义。

在您的情况下，ReSharper的建议会使代码更糟。因此，请忽略它。或更好：不要使用建议的转换，但要对如何改进代码进行一些思考。请注意，您可能多次分配了相同的变量，但是只有最后一次分配才有效，因为前一次分配只会被覆盖。这看起来确实像个错误。ReSharpers的建议不能解决该错误，但是确实使一些可疑的逻辑正在变得更加明显。

我认为，这里更大的一点是，循环的目的决定了在循环内组织流程的最佳方式。如果要在循环浏览其余元素之前先过滤掉某些元素，则continue尽早删除是有意义的。但是，如果您要在一个循环中执行不同类型的处理，则使之if真正明显可能更有意义，例如：

for(obj in objectList) {
    if(obj == null) continue;
    if(obj.getColour().equals(Color.BLUE)) {
        // Handle blue objects
    } else {
        // Handle non-blue objects
    }
}

请注意，在Java Streams或其他功能惯用语中，可以使用以下方法将过滤与循环分离：

items.stream()
    .filter(i -> (i != null))
    .filter(i -> i.getColour().equals(Color.BLUE))
    .forEach(i -> {
        // Process blue objects
    });

顺便说一句，这是我喜欢Perl的if（unless）倒置到单个语句的原因之一，它允许以下类型的代码，我觉得这很容易阅读：

foreach my $item (@items) {
    next unless defined $item;
    carp "Only blue items are supported! Failed on item $item" 
       unless ($item->get_colour() eq 'blue');
    ...
}