使用if（0 == foo（））而不是（foo（）== 0）有什么好处？

我发现有些程序员想在比较运算符中这样编写代码。我发现它是更难以阅读...使用if（0 == foo（））而不是（foo（）== 0）有什么好处？

if (0 == foo()){ 
    .... 
}

是否有可读性的长期foo() == 0之间有什么不同？使用0 == foo（）的优点是什么？

来源

2011-07-25 Kit Ho

我和你在一起，我觉得这不太可读（因为它不自然）。但是大约十年前推出了第一个，因为它可以避免意外的分配，当你忘记使用'=='并且使用'='代替时。就我个人而言，我发现这个论点非常微弱，因为编译器实际上会警告你（并且我用能够将所有警告转换为错误的标志进行编译，所以它无法为我编译，所以它永远不会成为问题）。 –

@Martin：如果我没有弄错，那么这个论点更适用于C，如果我没有弄错的话，那么你就不会得到这个警告。 – JAB

无我认为最好的理由这样做是这样的：

0 == foo

是确保你不要忘记一=这将使它

if (0 = foo)

这通常会提高一个编译器错误而不是

if (foo = 0)

它创建了一个难以发现的错误。

来源

2011-07-25 16:43:34 cellcortex

和几乎每一个C++编译器会发出警告这一点。当我写'if（foo = 0）'之类的东西时，我会在Visual C++中得到警告C4706：在条件表达式中的赋值。我设置我的编译器将警告转化为错误，所以我其实并没有被这个问题所困扰。 –

在性能方面，没有。

可读性是主观的;我个人觉得0 == foo()比foo() == 0略难读。

我所看到的支持if (0 == var)的唯一参数是，如果您不小心将此输入为if (0 = var)，编译器会发出抱怨。但是，大多数现代编译器在看到if (var = 0)时会发出警告，使参数无效。此外，由于if (foo() = 0)不是有效代码，因此这种思路甚至不适用于您的情况。

来源

2011-07-25 16:42:13 NPE

是的，我同意你的看法，这就是为什么我很好奇为什么有些人喜欢用这种方式进行编码。 –

这种风格的优点是，在所有情况下，如果您键入=而不是==，则因为无法分配给数字，因此在所有情况下编译器都可以保证可以投诉。

例如

bool a = 1; 
    if (0 = a) 
    { } 
    else if(1 = a) 
    { }

将不能编译，而

bool a = 1; 
    if (a = 0) 
    { } 
    else if(a = 1) 
    { }

是不是非法的（这是可能产生编译器警告）

这么说，我都认为是容貌丑陋的，通常是相反的。

来源

2011-07-25 16:43:08 Tom

无论如何，编译器会抱怨，因为'int'不是'if'条件所要求的'boolean'表达式。 –

由于编译器无论如何都会产生警告，因此它是一个优点的弱点。 –

完全一致，只是给一个理由，为什么它有时做 – Tom

没有性能影响，人们这样做的原因是为了确保它们不会意外地键入=运算符而不是==比较运算符（因为编译器会抱怨不能指定常量）。

我发现可读性惩罚比我喜欢的更多，所以我不这样做。其他人显然已经习惯了它。

来源

2011-07-25 16:43:58 gbjbaanb

在这种情况下，没有区别，但在比较字符串时，首先使用字符串常量以避免空指针异常是个不错的主意。

即

if ("somestring".equals(someVarString)) { 
// doSomething 
}

所以someVarString可以为null，并且测试仍然有效。如果翻转测试鉴于：

if (someVarString.equals("somestring")) { 
// doSomething 
}

这将导致NPE如果someVarString为null。

来源

2011-07-25 16:45:00

这是一个很好的观点 –

使用if（0 == foo（））而不是（foo（）== 0）有什么好处？

回答

相关问题