Quelle est la meilleure pratique: MethodReturnsBoolean == true/false OU true/false == MethodReturnsBoolean

Question

Je suis en train d'écrire:

if(Class.HasSomething() == true/false) 
{ 
    // do somthing 
} 
else 
{ 
    // do something else 
} 

mais je l'ai aussi vu des gens qui font le contraire:

if(true/false == Class.HasSomething()) 
{ 
    // do somthing 
} 
else 
{ 
    // do something else 
} 

Y at-il un avantage à faire l'un ou l'autre en termes de performance et de vitesse? Je ne parle pas du style de codage ici.

Answer 1

Le deuxième exemple est ce que j'ai entendu appelé "Yoda conditions"; "False, la valeur de retour de cette méthode doit être". Ce n'est pas la façon dont vous le dites en anglais et, par conséquent, parmi les programmeurs anglophones, c'est généralement méprisé.

En ce qui concerne les performances, il n'y a vraiment aucune différence. Le premier exemple est généralement meilleur grammaticalement (et donc pour la lisibilité), mais étant donné le nom de votre méthode la "grammaire" impliquée (et le fait que vous comparez bool à bool) rendrait la vérification d'égalité redondante de toute façon. Donc, pour une vraie déclaration, je voudrais simplement écrire:

if(Class.HasSomething()) 
{ 
    // do somthing 
} 
else 
{ 
    // do something else 
} 

Ce serait progressivement plus rapide, que le bloc a essentiellement si() intégré par rapport à l'égalité, donc si vous codez if(Class.HasSomething() == true) le CLR évaluerez if((Class.HasSomething() == true) == true) . Mais, nous parlons ici d'un gain de quelques horloges (pas des millisecondes, pas des tics, mais des horloges, celles qui arrivent 2 milliards de fois par seconde dans les processeurs modernes).

Pour une condition fausse, il s'agit d'un lien entre l'utilisation de l'opérateur not: if(!Class.HasSomething()) et l'utilisation d'une comparaison à false: if(Class.HasSomething() == false). Le premier est plus concis, mais il peut être facile de rater ce petit point d'exclamation dans une expression complexe (d'autant plus qu'il se produit avant toute l'expression) et donc je considérerais équation avec false pour s'assurer que le code est lisible.

Answer 2

Ils sont tous deux équivalents, mais ma préférence est

if(Class.HasSomething()) 
{ 
    // do something 
} 
else 
{ 
    // do something else 
} 

... pour plus de simplicité.

Answer 3

Vous ne verrez aucune différence de performance.

L'option correcte est

if (Whatever()) 

Le seul moment où vous devriez écrire == false ou != true est en matière de bool? s. (Auquel cas les quatre options ont des significations différentes)

Answer 4

Vous ne verrez aucune différence de performance, que ce soit la comparaison est traduit dans le même IL ...

Answer 5

if(Class.HasSomething()) 
{ 
    // do somthing 
} 

est mon chemin. Mais mieux vaut essayer d'éviter un appel de plusieurs méthodes de HasSomething(). Mieux exposer la valeur de retour une fois et le réutiliser.

Answer 6

vous ne devriez pas écrire non plus.

Ecrire

if(Class.HasSomething()) 
{ 
    // do something 
} 
else 
{ 
    // do something else 
} 

à la place.Si Class.HasSomething() est déjà un booléen, il est inutile de le comparer à un autre booléen

Answer 7

Il n'y a aucun avantage de performance ici. Ce style de codage est utilisé pour se prémunir contre la situation où les types de programmeurs = au lieu de ==. Le compilateur cathoc parce que vrai/faux sont des constantes et ne peut pas être assigné une nouvelle valeur

Answer 8

Certains programmeurs C plus anciens préfèrent les "Conditions Yoda", car si vous utilisez accidentellement un signe d'égales simples, vous obtiendrez un erreur de compilation de temps sur l'affectation à une constante:

if (true = Foo()) { ... } /* Compile time error! Stops typo-mistakes */ 
if (Foo() = true) { ... } /* Will actually compile for certain Foo() */ 

Même si cette erreur ne sera plus compiler en C#, les vieilles habitudes ont la vie dure, et beaucoup de programmeurs collent au style développé en C.

---

Personnellement, j'aime la forme très simple pour Tru e déclarations:

if (Foo()) { ... } 

Mais pour les déclarations Faux, j'aime une comparaison explicite.
Si j'écris le plus court !Foo(), il est facile de regarder par-dessus le ! lors de l'examen du code plus tard.

if (false == Foo()) { ... } /* Obvious intent */ 
if (!Foo()) { ... }   /* Easy to overlook or misunderstand */ 

Answer 9

Pour le cas de booléens, je vous recommande de ne: il suffit d'utiliser if (method()) et if (!method()). Pour le cas des choses autres que les booléens, la convention d'utiliser yoda-speak, par ex. if (1 == x) est venu pour éviter les erreurs, car if (1 = x) va lancer une erreur de compilation alors que if (x = 1) ne le fera pas (c'est du code valide en C, mais ce n'est probablement pas ce que vous vouliez). En C#, une telle déclaration n'est valide que si la variable était un booléen, ce qui réduit le besoin de faire cela.