我读了一些遗留代码:
if ( 1 || !Foo() )
是否有任何理由不写:
if ( !Foo() )
答案 0 :(得分:134)
两者不相同。第一个永远不会评估Foo()
,因为1
会使||
短路。
为什么要这样做 - 可能有人想强制进入then
分支进行调试,并将其留在那里。也可能是这是在源代码控制之前编写的,因此他们不希望代码丢失,而是暂时绕过 。
答案 1 :(得分:44)
if (1 || !Foo() )
将永远满意。由于short-circuits evaluation,我们甚至无法联系到!Foo()
。
如果您想确保if
下方的代码会被执行,但您不想删除其中的真实条件,可能是因为调试目的。
可能对您有所帮助的其他信息:
if(a && b)
- 如果a
为false
,则b
不会被检查。 if(a && b)
- 如果a
为true
,则会检查b
,因为如果它是false
,则表达式为{{} 1}}。false
- 如果if(a || b)
为a
,则true
不会被检查,因为无论如何这都是b
。true
- 如果if(a || b)
为a
,则会检查false
,因为如果b
为b
,那么它就会被true
是true
。强烈建议为此目的设置一个宏,比如DEBUG_ON 1
,这样可以更容易理解程序员的意思,而不是魔术数字在代码中(谢谢@grigeshchauhan)。
答案 2 :(得分:11)
1 || condition
无论condition
是否为真,始终为真。在这种情况下,condition
甚至从未被评估过。以下代码:
int c = 5;
if (1 || c++){}
printf("%d", c);
输出5
,因为c
永远不会增加,但如果您将1
更改为0
,则实际调用c++
,从而生成输出{ {1}}。
通常的实际用法是,当您想要测试某些代码时,只有在满足评估为true的条件时才会被调用:
6
这种方式永远不会评估if (1 || condition ) {
// code I want to test
}
,因此始终会调用condition
。但它绝对不一样:
// code I want to test
这是一个声明if (condition) { ...
将被实际评估的声明(在你的情况下condition
将被调用)
答案 3 :(得分:10)
问题得到了正确回答 - 区别在于操作的右侧是短路的,这表明这是强制进入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的已检入代码。这段代码永远不应该以这种方式编写,因为它显然不会传达意图。它永远不应该被签入(或者已被允许签入)(源代码控制?同行评审?)并且绝对不允许以当前形式在生产中执行。