为什么一些有经验的程序员会在变量之前写出比较值？

Question

可能重复:
如何检查等于？(0 == i)或(i == 0)
为什么人们经常在C#中看到"null!= variable"而不是"variable!= null"？

我一直在看一个奇怪的教程以及一些DirectX代码,并注意到许多有经验的C++程序员用以下方式编写表达式:

(<constant> == <variable>)

而不是我的传统智慧似乎更喜欢:

(<variable> == <constant>)

例如if (NULL == ptr)而不是if (ptr == NULL).我更喜欢第二种选择,如果没有其他原因选择前者,我的理由是变量似乎是表达式的"接收"端.

但我怀疑前者用于避免无意中通过使用=而不是将变量的值赋给变量==.这是对的吗？

Answer 1

过去就是这种情况,是的.当然,现在几乎所有的编译器都会对if()条件中的任务发出警告,因此只有那些经常压制警告的人才能获得优势.

抑制警告将导致比意外任务更大的问题. (13认同)
当大多数编码标准现在说出警告错误时,代码将始终编译干净.这只是考虑旧式(并且在个人说明中我发现它稍微难以阅读,因为它不是一种自然的思考方式). (3认同)
@Peter:是的,但默认情况下会禁止警告.您必须使用`-Wparentheses`或`-Wall`启用此警告.我建议总是使用`-Wall -Wextra`进行编译. (2认同)

Answer 2

对,那是正确的.它是检测错字=而不是==.

Answer 3

这被称为"Yoda Conditional"!

我非常喜欢这个词,因为:

if(Light::On == light)

读作:

"如果亮了"

如上所述,这用于防止错误分配.可以说这种做法是基于现代IDE的陈旧,但我仍然认为这是一种很好的做法.

Answer 4

因为你不能为一个常量赋值,所以如果你错误地放了=而不是==编译器会抛出一个错误,提醒你

Answer 5

这是一个常见的理由,因为您不希望将常量推到屏幕的最右侧,并且表达方式很长.后一种说法对我来说从未听起来特别有说服力,前者现在并不是真正有效,因为任何自尊的编译器都会发出警告(你会编译警告 - 错误,不是吗？:-) .

编辑:我刚刚看到了新的Xcode 4预览版,只看他们选择的示例来说明他们的新"Fix-it"功能!

我讨厌警告 - 错误!arrrg! (3认同)
@Martin,@ Gianni,@ Nathon:是的,有些情况下编译器过于谨慎,(AFAIK,gcc不发出类似C4800的警告,只发出MSVC).但这种抗议并不能证明让警告自由积累的政策是正确的.@Nathon,特别是:"当然我会解决它",这是我经常听到的一种副歌,而且经常在几个月之后,"哦,废话,我打算解决这个问题!" 经过为期两天的狩猎探险之旅.这是经典的"煮青蛙"心态; 一旦你每次构建达到100个警告,就很难发现真正的问题. (2认同)

Answer 6

捕捉分配和比较之间的差异。

如果你的意思是：

if (ptr == foo)

但是输入

if (ptr = foo)

if仍然是有效代码，因为ptr = foo将ptr其设置为值后，将对其进行布尔检查foo。显然，您不需要这样做。

但是，我发现它极大地损害了可读性，并且考虑到大多数IDE和预处理器无论如何都会抓住这种情况，因此请不要使用这种样式。