这可能是一个愚蠢的问题，但是好奇心已经变得更好。我最近看到的代码似乎"颠倒"了关系运算符的表达式顺序，例如：

if (0 == someVariable)

与我通常看到/写的相反：

if (someVariable == 0)

对我来说，第二种方法似乎更具可读性和直观性，所以我想知道是否有某些原因让我看到第一种方法？从逻辑上讲，两个语句得出的结果相同，因此，编写方式仅仅是个人喜好吗？

解决方案

顺序并不重要，但是前者暗示它
是我们要检查的零。公约规定使用后者。

第一种方法是提醒我们不要在IF语句中进行赋值的方法，这可能会对某些语言(C / C ++)造成灾难性后果。在C语言中，如果我们设置布尔值，则只会被此咬住。

可能致命的C代码：

if (succeeded = TRUE)
{
    // I could be in trouble here if 'succeeded' was FALSE
}

在C / C ++中，当我们希望VAR == CONSTANT时，任何变量都容易受到VAR = CONSTANT的问题的影响。因此，通常是习惯于对IF语句重新排序，以便在遇到这种错误时收到编译错误：

if (TRUE = succeeded)
{
    // This will fail to compile, and I'll fix my mistake
}

在Conly中，布尔值很容易受到这种影响，因为只有布尔表达式在if语句中有效。

if (myInteger = 9)
{
    // this will fail to compile
}

因此，在Cworld中，没有必要采用CONSTANT == VAR样式，除非我们对此感到满意。

我了解这是个人喜好。尽管通过将变量放在第二位可以确保我们不会意外地将常量分配给用来隐藏c开发人员的变量。这可能就是为什么我们在cas开发人员切换语言中看到它的原因。

后一种格式是C语法的遗留形式，在这种情况下，如果我们无意中遗漏了一个等号，则会进行赋值，而不是进行比较。

但是，我们当然不能分配给数字文字，因此，如果像第二个示例那样编写它，则会得到编译器错误，而不是错误。

但是，在C＃中，我们不能无意间执行此操作，因此这并不重要。

在C和C ++中的主要原因是易于键入

if (someVariable = 0) {
    ...
}

总是失败，并且将someVariable设置为0。

我个人更喜欢变量优先样式，因为它读起来更自然，并且希望我不要忘记使用==而不是=。

如果在if中分配常量，许多C和C ++编译器都会发出警告。
Java和通过在if子句中禁止非布尔表达式来避免这个问题。
Python通过将赋值指定为语句而不是表达式来避免此问题。

除了平等，我经常碰到类似的代码

if (0 > number)

或者

if (NULL != pointer)

在C / C ++中甚至根本没有犯错的危险！这是一种本来就很好的教学技巧已变成一种普通的坏习惯的情况。