我想补充的是，这些倒置的if是有名称的-保护条款。我一有机会就用它。

我讨厌阅读一开始只有两屏代码的代码。只要求if的倒数，然后返回。这样就没人会浪费时间刷屏幕了。

http://c2.com/cgi/wiki?GuardClause

我的想法是“在函数中间”的返回不应该那么“主观”。 原因很简单，以下面的代码为例:

    function do_something( data ){

      if (!is_valid_data( data )) 
            return false;


       do_something_that_take_an_hour( data );

       istance = new object_with_very_painful_constructor( data );

          if ( istance is not valid ) {
               error_message( );
                return ;

          }
       connect_to_database ( );
       get_some_other_data( );
       return;
    }

也许第一个“回报”不是那么直观，但这是真正的储蓄。 有太多关于干净代码的“想法”，只是需要更多的实践来摆脱他们“主观的”坏想法。

从理论上讲，反转if可以提高分支预测的命中率，从而提高性能。在实践中，我认为很难确切地知道分支预测将如何表现，特别是在编译之后，所以我不会在日常开发中这样做，除非我正在编写汇编代码。

更多关于分支预测的信息。

我不确定，但我认为，r#试图避免远跳。当你有IF-ELSE时，编译器会做这样的事情:

条件false ->远跳到false_condition_label

true_condition_label: instruction1 .．. instruction_n

false_condition_label: instruction1 .．. instruction_n

结束块

如果condition为真，则没有跳转，也没有L1缓存的滚出，但是跳转到false_condition_label可能很远，处理器必须滚出自己的缓存。同步缓存的开销很大。r#尝试将远跳转替换为短跳转，在这种情况下有更大的概率，所有指令都已经在缓存中。

我想这要看你喜欢什么了，如前所述，没有统一的意见。 为了减少麻烦，您可以将这种警告减少为“提示”。

正如其他人所提到的，不应该对性能造成影响，但还有其他考虑因素。除了这些合理的担忧，在某些情况下，这也会让你陷入困境。假设你处理的是一个double:

public void myfunction(double exampleParam){
    if(exampleParam > 0){
        //Body will *not* be executed if Double.IsNan(exampleParam)
    }
}

将其与看似等效的反转进行对比:

public void myfunction(double exampleParam){
    if(exampleParam <= 0)
        return;
    //Body *will* be executed if Double.IsNan(exampleParam)
}

所以在某些情况下，看起来是正确的a颠倒的if可能不是。