使用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）有什麼好處？

回答

相關問題