【问题标题】:Best practice: if logic control最佳实践:如果逻辑控制
【发布时间】:2010-11-15 07:22:19
【问题描述】:

关于编码标准、速度和效率,对于这种情况,以下哪项是更好的编程实践?

function foo() {
  if(bar)   { return 0; }
  if(baz)   { return 0; }
  if(qux)   { return 0; }
}

function foo() {
  if(bar || baz || qux) { return 0; }
}

我倾向于第一个,因为只需要评估一个条件,因此会更快,但是拥有多个 returns 并不好......?

//编辑

我要应用的语言主要是 PHP 和 Javascript,可能是 C++ 和 Ruby。

【问题讨论】:

  • 如果bar || baz || qux 为假,你的方法应该返回什么?
  • @Mark - 它实际上来自更大的上下文,所以为了简洁起见,我删除了其他内容。不过还是谢谢你的提醒。

标签: if-statement coding-style


【解决方案1】:

如今几乎每一种编程语言 uses short-circuit evaluation for ||,这意味着这两个示例在控制流和性能方面将是等效的。

如果它们分布在整个函数中并且它们返回不同的东西,确实应该避免使用多个返回,因为这会降低可读性。另一方面,具有检测不可接受的条件并停止执行流程的提前退出条件是相当标准的:

function getFriendList() 
{
  if (! has_internet_connection() ) return null;
  if (! is_logged_in() ) return null;

  return server.getFriendList();
}

【讨论】:

    【解决方案2】:

    关于您的第二个示例,|| 在大多数语言中是 short-circuiting,因此只会评估必要的条件。例如,如果 bar 计算结果为 true,则不会计算 bazqux

    知道这一点,我可能会选择第二个例子。

    【讨论】:

      【解决方案3】:

      后者不过为:

      function foo()
      {
      
         var result = 1;
      
         if(bar || baz || quz)
         {
             result = 0;
         }
      
         return result;
      }
      

      用“return”随意退出代码是不好的做法,会使调试成为一场噩梦——尤其是当您尝试调试的是其他人的代码时!控制流应该总是在函数的底部退出!

      【讨论】:

        【解决方案4】:

        在 C# 中,您可以使用第二个版本,因为在性能方面相同但看起来更好。如果bar 为真,则不再检查其他标志。

        【讨论】:

          【解决方案5】:

          在第二种情况下,由于您使用的是逻辑或,因此仅在必要时才检查第二个条件,因此我想使用更好的编码标准。

          【讨论】:

            【解决方案6】:

            我认为后一个示例在编码方面更好。在 OR 语句中,至多一个条件为真,则该语句为真。因此,如果第一个条件为真,则不会查看其他条件。速度或效率没有损失。

            【讨论】:

              【解决方案7】:

              这完全取决于语言。许多语言会短路评估,因此,如果bar 为真,则不会评估其他两个,并且在这种情况下,任何半体面的编译器都会将它们优化为相同的东西。在您提到的四种语言(C++、Ruby、PHP 和 Javascript)中,它们都进行短路评估。

              而且,尽管“避免多次退货”人群会告诉你什么,这是你应该像绵羊一样遵循的规则。这是为了避免很难看到返回(或循环中断)发生在哪里的情况。您的第一个解决方案不会比您的第二个解决方案更容易遇到这个问题。

              在不了解其背后原因的情况下盲目遵循教条应该是一种可以受到痛苦折磨的罪行。

              【讨论】:

              • 那时我可能会 24/7 全天候在水上运动……但感谢您的建议。我认为 Rob 的 return 变量解决了“难以看到回报”的情况?
              • 是的,但我认为自己没有必要,因为原始代码很好。 Rob 的回答解决了另一个方面,即没有返回任何内容的代码路径,但我认为这只是一个 sn-p 并且您意识到这是一个坏主意(无论如何,这是编译器/解释器应该捕获的东西)。实际上,我更喜欢 Rob 的原始解决方案,因为他对我来说看起来很乱,但这只是个人喜好 - 它仍然有效。
              • 好的,谢谢@pax (+1) 和其他人。我将@Victor 作为一个很好的总结,而且因为他的代表明显少于 80k。 :p
              猜你喜欢
              • 1970-01-01
              • 2021-06-21
              • 2021-11-08
              • 2016-06-17
              • 1970-01-01
              • 2018-05-12
              • 1970-01-01
              • 1970-01-01
              • 2017-01-19
              相关资源
              最近更新 更多