Vergleichsoperator Ausdruck Reihenfolge

Question

Dies ist wahrscheinlich eine dumme Frage, aber die Neugierde hat die bessere von mir bekommen. Ich habe Code zu sehen, in letzter Zeit, dass die Reihenfolge der Ausdrücke für relationale Operatoren beispiel auf „reverse“ scheint.

if (0 == someVariable)

Im Gegensatz zu dem, was ich normalerweise sehen / schreiben:

if (someVariable == 0)

Für mich scheint die zweite Methode besser lesbar und intuitiv, so frage ich mich, ob es einen Grund ich die erste Methode zu sehen bin? Logisch, bewerten beide Aussagen zum gleichen Ergebnis, so ist es nur eine Frage der persönlichen Vorliebe, wie sie geschrieben sind?

Answer 1

Ich verstehe, dass dies persönliche Präferenz. Obwohl durch die Variable setzt zweites können Sie sicherstellen, dass Sie nicht versehentlich die Konstante die Variablen zuweisen, die c-Entwickler concearn verwendet. Dies ist wahrscheinlich, warum Sie es in c # sehen als Entwickler Sprache wechseln.

Answer 2

Reihenfolge keine Rolle spielt, jedoch impliziert die ehemalige, dass es s die Null Sie überprüfen. Konvention diktiert die Verwendung von hte letzteren.

Answer 3

Der Hauptgrund in C und C ++ ist, dass es einfach ist, den Typ

if (someVariable = 0) {
    ...
}

, die immer versagt und setzt auch someVariable auf 0 zurück.

Ich persönlich bevorzuge die Variable-first-Stil, weil es natürlich liest, und hoffe nur, dass ich nicht vergessen == verwenden nicht =.

Viele C und C ++ Compiler gibt eine Warnung aus, wenn Sie eine Konstante innerhalb eines if zuweisen. dieses Problem Java und C # zu vermeiden durch das Verbot nicht-Booleschen Ausdrücken in if Klauseln. Python vermeidet, dieses Problem durch Zuweisungen eine Aussage zu machen, keinen Ausdruck.

Answer 4

Die erste Methode besteht als eine Möglichkeit, sich zu erinnern, nicht Zuweisungen in einer IF-Anweisung zu tun, die in einigen Sprachen (C / C ++) disasterous Folgen haben könnte. In C # werden Sie nur von diesem gebissen werden, wenn Sie booleans sind zu setzen.

Tödlicher C-Code:

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

In C / C ++, eine Variable für dieses Problem von VAR anfällig = CONSTANT, wenn Sie VAR bestimmt == CONSTANT. So ist es oft die Gewohnheit Ihre IF-Anweisung neu zu ordnen einen Compiler-Fehler zu erhalten, wenn Sie diese flub oben:

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

In C # sind nur booleans auf diese anfällig, da nur Boolesche Ausdrücke gültig sind in einer if-Anweisung.

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

Also, in der C # Welt ist es nicht notwendig, die CONSTANT == VAR Stil zu übernehmen, es sei denn, Sie so mit dem Tun vertraut sind.

Answer 5

Neben der Gleichheit ich oft über Code kommen wie

if (0 > number)

oder

if (NULL != pointer)

Dabei ist es nicht einmal die Gefahr besteht, einen Fehler zu machen in C / C ++! Es ist eine jener Situationen, in denen eine gut gemeinte Lehre Technik in eine einfache schlechte Gewohnheit geworden ist.

Answer 6

Das letztgenannte Format eine übriggebliebene von C-Syntax ist, wo, wenn Sie versehentlich von dem Gleichheitszeichen eine ausgelassen, es einen Auftrag hat, anstelle eines Vergleichs.

Sie können jedoch selbstverständlich nicht auf Zahlenliteral zuweisen, so dass, wenn Sie es wie das zweite Beispiel schreiben, würden Sie einen Compiler-Fehler, und nicht einen Fehler.

In C #, aber man kann diese nicht versehentlich tun, so ist es nicht wirklich wichtig.