C#：嵌套条件语句与 continue 语句

Question

最近使用 ReSharper 时，建议我通过反转 if 条件并使用 continue 语句来减少某些地方的嵌套。

嵌套条件：

foreach(....)
{
    if(SomeCondition)
    {
        //do some things

        if(SomeOtherNestedCondition)
        {
            //do some further things
        }
    }
}

继续语句：

foreach(....)
{
    if(!SomeCondition) continue;

    //do some things

    if(!SomeOtherNestedCondition) continue;

    //do some further things
}

我理解为什么您希望减少性能和内存问题的嵌套的一些逻辑，以及这两个片段如何相互等同其他，但是从我的开发背景来看，之前示例在阅读代码时更容易理解。

您更喜欢哪种方法？为什么？您是否在日常代码中使用 continue 来代替嵌套的 if 语句？

Answer 1

简短的回答：

我倾向于使用缩进，这意味着发生了一些真正的决策逻辑，即。预期有多个可能执行路径的逻辑。

更长的答案：

我通常更喜欢缩进块而不是前面的“中断”语句（继续、break、return或抛出）。

原因：在我看来，破坏语句通常会使代码更难阅读。如果缩进代码，很容易找到某些决策逻辑发生的位置：这将是缩进较少的代码的第一行。如果您使用带有反转条件的中断语句，则必须做更多的工作来了解代码如何分支以及在什么情况下跳过某些代码。

对我来说有一个值得注意的例外，即在方法开头验证参数。我将此代码格式化如下：

if (thisArgument == null) throw new NullArgumentException("thisArgument");
if (thatArgument < 0) throw new ArgumentOutOfRangeException("thatArgument");
...

原因：因为我不希望实际抛出这些异常（也就是说，我希望正确调用该方法；调用函数负责检测无效输入） ，IMO），我不想缩进所有其余的代码来处理不应该发生的事情。

Answer 2

使用 continue 样式代码；您将如何处理不依赖于 SomeOtherNestedCondition 的第三个操作，这使得代码的顺序很重要，IMO 使其难以维护。

例如：

foreach(....) 
{ 
    if(!SomeCondition) continue; 

    //do some things 

    if(!SomeOtherNestedCondition) continue; 

    //do some further things 

    if(!SomeSecondNonNestedCondition) continue;

    // do more stuff
}

当 SomeOtherNestedCondition 导致 continue; 发生，但 SomeSecondNonNestedCondition 仍应执行时，会发生什么？

我会重构每一位“代码”，并使用嵌套的 if() 来调用每个重构的方法，并且保留嵌套结构。

Answer 3

结合使用两者。我在循环顶部使用 if(condition) continue; 和 if(condition) return; 来验证当前状态，并嵌套 if 进一步声明以控制我想要完成的任何事情的流程。

Answer 4

简单的回答。哪一个更容易阅读和理解。

Answer 5

在内存或性能方面没有区别。底层 IL 只是分支/跳转指令的选择，因此它们是否跳回循环顶部或“else”语句并不重要。

您应该选择更容易阅读的一个。我个人更喜欢避免“继续”，但如果您有很多级别的嵌套，那么您的第二个示例可能更容易理解。

Answer 6

使用 continue 使大部分代码处于常规过程代码的级别。
否则，如果有五个检查，您将缩进方法的“内容”10 或 20 个字符，具体取决于缩进大小，而这些是 10/20 个字符，您必须滚动才能看到更长的行。

Answer 7

Continue 原意：当任何条件为 false 时，代码不会被处理。这是情况的示例：

class Program
{
    static bool SomeCondition = false;
    static bool SomeOtherNestedCondition = false;
    static void Main(string[] args)
    {    
        for (int i = 0; i < 2; i++)
        {
            if (SomeCondition)
            {
                //do some things

                if (SomeOtherNestedCondition)
                {
                    //do some further things
                }
            }
            Console.WriteLine("This text appeared from the first loop.");
        }
        for (int i = 0; i < 2; i++)
        {
            if (!SomeCondition) continue;

            //do some things

            if (!SomeOtherNestedCondition) continue;

            //do some further things
            Console.WriteLine("This text appeared from the second loop.");
        }
        Console.ReadLine(); 
    }
}

输出将是：

Answer 8

但是从我的开发背景来看，前面的示例在阅读代码时更容易理解。

嗯 - 我想，这是你的个人意见。例如，我尝试避免这种嵌套，因为在我看来，这会使代码更难阅读。

如果您比“之后”版本更喜欢“之前”版本，请使用它。
只需配置 ReSharper，它就会建议您真正想要的内容。

永远记住：ReSharper 是一个相当“愚蠢”的重构工具——它无法取代开发人员。它只能通过做一些愚蠢的复制和粘贴工作来帮助他。
即使在 ReSharper 建议相反重构的情况下，ReSharper 所做的一些重构也会导致结果。

因此，不要将 ReSharper 的建议视为最佳实践，而应将其视为您可以采取的可能性。

顺便说一句：您应该在这里考虑性能因素 - 如果性能确实存在显着差异，我会感到惊讶。

Answer 9

一般来说，我发现最好总是以任何排除的条件开始语句块，因为它会降低复杂性，但更重要的是在进一步执行之前抛出不兼容的情况，这可以提高代码和内存性能。这也确保了您的条件在维护期间的安全性，即不太可能将无效场景传递到不属于它们的代码中。

另外，我认为两者中的第二个个人更具可读性，因为您没有作用域层混淆了可用的内容，很容易在以后的某一层中创建一个变量，而没有意识到它在另一层中不可用，或者必须管理它们以进行适当的修改等。

这不仅仅是继续循环，而是这也指方法应返回的条件； 而不是让方法启动

if (valid)
{
    do stuff;
}

它应该始终启动，

if (notValid)
{
    return;
}

Answer 10

不应该有显着的性能差异，这都是关于可读性的。我个人认为后者更容易阅读。更少的嵌套，更容易阅读。