2009-06-16 9 views
1

J'ai vu cela autour, mais jamais entendu une explication claire de pourquoi ... C'est vraiment pour n'importe quelle langue, pas seulement C# ou VB.NET ou Perl ou autre. Lorsque vous comparez deux éléments, la valeur "vérification" est parfois placée sur le côté gauche au lieu de la droite. Logiquement à moi, vous listez votre variable d'abord, puis la valeur à laquelle vous comparez. Mais j'ai vu l'inverse, où la "constante" est listée en premier.Ordre des articles comparés?

Quel gain (le cas échéant) y a-t-il dans cette méthode?

Ainsi, au lieu de:

if (myValue > 0) 

Je l'ai vu:

if (0 < myValue) 

ou

if (Object.GimmeAnotherObject() != null) 

est remplacé par:

if (null != Object.GimmeAnotherObject()) 

Des idées là-dessus?

TIA! Kevin

+0

Je pense que C spécifique, ou langage avec assignation-dans-si-instruction spécifique – Paco

Répondre

8

Certains développeurs ont mis la constante sur la gauche comme si

if(0 = myValue) 

Ceci est parce que vous obtiendrez une erreur du compilateur, puisque vous ne pouvez pas affecter une valeur 0. Au lieu de cela, vous devrez changer pour

if(0 == myValue) 

Cela empêche beaucoup de débogage douloureux sur la route, car en tapant

if(myValue = 0) 

est parfaitement légal, mais vous avez très probablement voulu dire

if(myValue == 0) 

Le premier choix n'est pas ce que vous voulez. Il va subtilement changer votre programme et causer toutes sortes de maux de tête. J'espère que cela clarifie!

+0

Gardez à l'esprit que dans de nombreuses nouvelles langues si (myValue = 0) n'est pas valide code myValue = 0 évalue à un nombre et si() ne fonctionne pas avec un nombre comme condition –

+0

@David Bienvenue dans le monde du pseudocode :) – samoz

2

Je ne pense pas qu'un simple règle comme mais la première constante ou la dernière constante n'est pas un choix très intelligent. Je crois que le chèque devrait exprimer la sémantique. Par exemple, je préfère utiliser les deux versions dans une vérification de portée.

if ((low <= value) && (value <= high)) 
{ 
    DoStuff(value); 
} 

Mais je suis d'accord sur les exemples que vous avez mentionnés - je le ferais, mais la constante dernière et ne voit aucune raison obviouse pour ce faire dans l'autre sens.

if (object != null) 
{ 
    DoStuff(object); 
} 
2

En C++ ces deux sont valides et compilent

if(x == 1) 

et

if(x=1) 

mais si vous écrivez comme ça

if(1==x) 

et

if(1=x) 

puis l'affectation à 1 est interceptée et le code ne sera pas compilé.

Il est considéré comme "plus sûr" de placer la variable const sur le côté gauche.

Une fois que vous prenez l'habitude de mettre la variable const à gauche pour l'affectation, il tend à devenir le mode de fonctionnement par défaut, c'est pourquoi vous voyez apparaître des contrôles à l'égalité et

1

Sa pratique de codage pour attraper des fautes de frappe comme '! =' tapé comme '=' par exemple.

Si vous avez une constante sur la gauche, tous les opérateurs d'affectation seront interceptés par le compilateur car vous ne pouvez pas l'affecter à une constante.

De nombreuses langues (en particulier C) permettent une grande flexibilité dans l'écriture de code. Alors que, la constante à gauche semble inhabituel pour vous, vous pouvez également les affectations de programme et conditionals ainsi que,

if (var1 = (var2 & var3)) { /* do something */ } 

Ce code obtiendrez le résultat booléen dans var1 et aussi/* faire quelque chose */si le résultat est vrai.

Une pratique de codage connexe consiste à éviter d'écrire du code où des expressions conditionnelles ont des affectations à l'intérieur de celles-ci; si le langage de programmation permet de telles choses. Vous ne rencontrez pas beaucoup de code depuis que les affectations dans les conditions sont inhabituelles, donc le code typique n'a pas de telles choses.

Il existe un bon article sur les pratiques de codage de langue au IBM DeveloperWorks qui est probablement encore pertinent pour les personnes qui écrivent dans cette langue.

+0

Vous devez lire le conditionnel ici attentivement pour remarquer le nombre de choses coincées dedans. Par exemple, en première lecture, avez-vous remarqué que var1 obtiendrait un peu de résultat ET de résultat.Et qu'un tel résultat est VRAI quand il est non nul. – nik

+0

L'écriture de code lisible et déboguible implique que de telles tromperies sont évitées. Laissez vos cascades se concentrer sur l'efficacité de votre code, pas dans sa 'calligraphie' :-) – nik

2

Pour .Net, il est hors de propos, que le compilateur ne vous laissera pas faire une cession dans un état comme:

if(x=1) 

parce que (comme tout le monde dit autre), il est une mauvaise pratique (parce qu'il est facile de manquer). Une fois que vous n'avez pas à vous soucier de cela, il est légèrement plus lisible de mettre la variable en premier et la valeur en second, mais c'est la seule différence - les deux côtés doivent être évalués.