ordre d'expression d'opérateur relationnel

Question

C'est probablement une question idiote, mais la curiosité a pris le dessus sur moi. Je vois du code récemment qui semble "inverser" l'ordre des expressions pour les opérateurs relationnels, par exemple:

if (0 == someVariable)

Contrairement à ce que je vois / écris normalement:

if (someVariable == 0)

Pour moi, la deuxième méthode semble plus lisible et intuitive, alors je me demande s’il ya une raison pour laquelle je vois la première méthode? Logiquement, les deux déclarations donnent le même résultat, est-ce donc une question de préférence personnelle quant à la manière dont elles sont écrites?

Answer 1

Je comprends que ce soit une préférence personnelle. Cependant, en plaçant la variable seconde, vous pouvez vous assurer de ne pas attribuer accidentellement la constante à la variable utilisée auparavant pour les développeurs. C’est probablement pour cette raison que vous le voyez en c # lorsque les développeurs changent de langue.

Answer 2

L'ordre n'a pas d'importance, cependant, le premier implique qu'il C'est le zéro que vous vérifiez. La convention dicte l’utilisation de ce dernier.

Answer 3

La principale raison en C et C ++ est qu'il est facile de taper

if (someVariable = 0) {
    ...
}

qui échoue toujours et définit également someVariable sur 0.

Personnellement, je préfère le style variable d'abord car il se lit de manière plus naturelle et j'espère que je n'oublie pas d'utiliser == et non = .

De nombreux compilateurs C et C ++ émettent un avertissement si vous affectez une constante dans un si . Java et C # évitent ce problème en interdisant les expressions non booléennes dans les clauses if . Python évite ce problème en faisant des attributions une déclaration et non une expression.

Answer 4

La première méthode existe pour vous rappeler de ne pas effectuer d'attribution dans une instruction IF, ce qui pourrait avoir des conséquences désastreuses dans certaines langues (C / C ++). En C #, vous ne serez piqué par ceci que si vous définissez des booléens.

Code C potentiellement fatal:

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

En C / C ++, toute variable est sujette à ce problème de VAR = CONSTANT alors que vous vouliez VAR == CONSTANT. Ainsi, il est souvent dans la coutume de réorganiser votre instruction IF afin de recevoir une erreur de compilation si vous déréglez ceci:

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

En C #, seuls les booléens y sont sensibles, car seules les expressions booléennes sont valides dans une instruction if.

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

Ainsi, dans le monde C #, il n'est pas nécessaire d'adopter le style CONSTANT == VAR, à moins que cela ne vous plaise.

Answer 5

En plus de l'égalité, je rencontre souvent du code comme

if (0 > number)

ou

if (NULL != pointer)

où il n’ya même pas de danger de se tromper en C / C ++! C’est l’une des situations où une technique d’enseignement bien intentionnée est devenue une mauvaise habitude.

Answer 6

Ce dernier format est un reste de la syntaxe C, où, si vous avez oublié par inadvertance l’un des signes d’égalité, il effectue une tâche au lieu d’une comparaison.

Cependant, vous ne pouvez bien sûr pas affecter un littéral numérique. Par conséquent, si vous l'écriviez comme dans le deuxième exemple, vous obtiendrez une erreur du compilateur et non un bogue.

En C #, cependant, vous ne pouvez pas le faire par inadvertance, cela n'a donc pas d'importance.