Is there any reason for using if(1 || !Foo())?

Is there any reason for using if(1 || !Foo())?

本文关键字：Foo if any there reason for using Is      更新时间：2023-10-16

我读了一些遗留代码：

if ( 1 || !Foo() )

有什么明显的理由不写：

if ( !Foo() )

两者是不一样的。第一个永远不会评估Foo()因为1会使||短路。

为什么这样做 - 可能有人想强制进入 then 分支以进行调试并将其留在那里。也可能是在源代码管理之前编写的，所以他们不希望代码丢失，而是暂时绕过。

if (1 || !Foo() )总是会满意的。 由于短路评估，甚至无法达到!Foo()。

当您想要确保将执行if下面的代码，但您可能出于调试目的不想删除其中的实际条件时，就会发生这种情况。

可能对您有帮助的其他信息：

  • if(a && b) - 如果a false，则不会检查b。
  • if(a && b) - 如果a true，则将检查b，因为如果它是false，表达式将被false。
  • if(a || b) - 如果a true，则不会检查b，因为这无论如何都是true。
  • if(a || b) - 如果a false，将检查b，因为如果b true，那么它将true。

强烈建议为此目的使用宏，例如DEBUG_ON 1，这样可以更轻松地理解程序员的意思，并且代码中不要有幻数(谢谢@grigeshchauhan(。

1 || condition

始终为真，无论condition是否为真。在这种情况下，甚至从未评估过condition。以下代码：

int c = 5;
if (1 || c++){}
printf("%d", c);

输出5，因为c永远不会递增，但是如果您将1更改为0，则实际将调用c++，从而使输出6。

通常的实际用法是，当您想要测试某些代码段时，该代码段正在调用，而计算结果仅为 true 的条件很少得到满足：

if (1 || condition ) {
    // code I want to test
}

这样condition永远不会被评估，因此// code I want to test总是被调用。但是，它绝对不同于：

if (condition) { ...

这是一个语句，实际将评估condition(在您的情况下，将调用Foo(

这个问题得到了正确的回答 - 区别在于 or 操作的右侧短路，这表明这是强制进入 if 块的调试代码。

但为了最佳实践，至少我对最佳实践的粗略尝试，我会建议替代方案，按偏好增加的顺序(最好是最后(：

注意：请注意，在我编写示例后，这是一个C++问题，示例是 C#。 希望你能翻译。 如果有人需要我，只需发表评论。

内联注释：

if (1 /*condition*/) //temporary debug

下线评论：

//if(condition)
if(true) //temporary debug

名称指示功能

//in some general-use container
bool ForceConditionForDebug(bool forcedResult, string IgnoredResult)
{
      #if DEBUG
          Debug.WriteLine(
              string.Format(
                  "Conditional {0} forced to {1} for debug purposes",
                  IgnoredResult,
                  forcedResult));
          return forcedResult;
      #else
          #if ALLOW_DEBUG_CODE_IN_RELEASE
              return forcedResult;
          #else
              throw new ApplicationException("Debug code detected in release mode");
          #endif
      #endif
}
//Where used
if(ForceConditionForDebug(true, "condition"))...
//Our case
if(ForceConditionForDebug(true, "!Foo()"))...

如果你想要一个真正可靠的解决方案，你可以向源代码管理添加一个存储库规则，以拒绝任何名为 ForceConditionForDebug 的签入代码。 这段代码不应该以这种方式编写，因为它显然不会传达意图。 它永远不应该被签入(或被允许签入((源代码管理？ 同行评审？ 而且绝对不应该允许它以当前的形式在生产中执行。

相关文章：