有什么理由使用if（1 ||！Foo（））？
我读了一些遗留代码：
if ( 1 || !Foo() ) 有没有看到为什么不写的原因：
if ( !Foo() )
这两个是不一样的。 第一个将永远不会评估Foo()因为1会使||短路 。
为什么这样做 – 可能有人想强制进入then分支进行debugging，并将其留在那里。 也可能是因为这是在源代码控制之前编写的，所以他们不希望代码丢失， 现在只是绕过了 。
if (1 || !Foo() )总会被满足。 !Foo()由于短路评估， !Foo()甚至不会到达。
当你想要确保if下面的代码被执行时，会发生这种情况，但是你不想删除它中的实际情况，可能是为了debugging目的。
其他信息可能会帮助您：
-
if(a && b)– 如果a是false，b将不被检查。 -
if(a && b)– 如果a是true，b将被检查，因为如果它是false，则expression式将是false。 -
if(a || b)– 如果a是true，b将不会被检查，因为无论如何这是true。 -
if(a || b)– 如果a是false，b将被检查，因为如果b是true那么它将是true。
强烈build议为此设置一个macros，例如DEBUG_ON 1 ，这样可以更容易理解程序员的含义，而不是在代码中包含幻数 （Thanks @grigeshchauhan）。
1 || condition
无论condition是否正确，总是如此。 在这种情况下， condition永远不会被评估。 以下代码：
int c = 5; if (1 || c++){} printf("%d", c);
输出5因为c永远不会增加，但是如果你改变1为0 ， c++将被实际调用，使输出6 。
这种情况通常的实际用法是当你想testing一些被调用的代码时，只有很less符合条件的情况才会被满足：
if (1 || condition ) { // code I want to test }
这种方式永远不会被评估，因此// code I want to test总是被调用。 不过这绝对不是一样的：
if (condition) { ...
这是一个condition将被实际评估的声明（在你的情况下， Foo将被调用）
这个问题得到了正确的回答 – 区别在于操作的右侧是短路的，提示这是强制进入if区块的debugging代码。
但是为了最佳实践的利益，至less我粗略地推荐了一个最佳实践，我会build议替代scheme，按照越来越偏好的顺序（最好是最后一个）：
注意：注意到我编码的例子后，这是一个C + +的问题，例子是C＃。 希望你能翻译。 如果有人需要我，只需发表评论。
在线评论：
if (1 /*condition*/) //temporary debug
线外评论：
//if(condition) if(true) //temporary debug
名称 – 指示function
//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()"))...
如果你想要一个真正强大的解决scheme，你可以添加一个存储库规则来源控制，以拒绝任何名为ForceConditionForDebug的检入代码。 这个代码不应该是这样写的，因为它显然不能传达意图。 它永远不应该被检查（或被允许检查）（源代码pipe理？同行评审？）而且它绝对不能被允许以其当前forms执行生产。
