"Si (0 == valeur) ..." ne fait-il pas plus de mal que de bien?
C'est l'une des choses que je déteste le plus quand je le vois dans le code de quelqu'un d'autre. Je sais ce que cela signifie et pourquoi certaines personnes le font de cette façon ("et si je mets accidentellement '=' à la place?"). Pour moi, c'est un peu comme quand un enfant descend les escaliers en comptant les marches à haute voix.
Quoi qu'il en soit, voici mes arguments contre:
- Il perturbe le flux naturel de lecture du code de programme. Nous, les humains, disons "si la valeur est nulle" et non "si le zéro est la valeur".
- Les compilateurs modernes vous avertissent lorsque vous avez une affectation dans votre état, ou en fait si votre état se compose uniquement de cette affectation, qui, oui, semble de toute façon suspecte
- N'oubliez pas de mettre le double '=' lorsque vous comparez des valeurs si vous êtes programmeur. Vous pouvez aussi oublier de mettre "!" lors du test de non-égalité.
Ah, oui, "Yoda conditionals" ("Si zéro la valeur est, exécutez ce code vous devez!"). Je signale toujours à quiconque prétend être "meilleur" des outils comme le peluches (1). Ce problème particulier a été résolu depuis la fin des années 70. La plupart des langages modernes ne compileront même pas une expression comme if(x = 10), car ils refusent de contraindre le résultat de l'affectation à un booléen.
Comme d'autres l'ont dit, ce n'est certainement pas un problème, mais cela provoque un peu de dissonance cognitive.
Il est désagréable car il impose une taxe mentale faible mais perceptible.
Les gens lisent de gauche à droite dans pratiquement tous les langages de programmation (et la plupart des langages naturels).
Si je vois 123 == x, La façon dont je l'analyse mentalement est:
123- alors quoi? informations incomplètes.==- eh bien, 123 est 123, pourquoi le tester ...x- ok, c'est ce qui nous inquiète. Ce n'est que maintenant que j'ai le contexte.- Revenez pour reconsidérer
123Et pourquoi x y est comparé.
Quand je vois x == 123 L'analyse mentale est:
x- Fournit du contexte, je sais de quoi parle la condition. Je peux choisir d'ignorer le reste. Sur la base du flux précédent, j'ai une bonne idée pourquoi et ce qui va arriver (et être surpris si c'est différent).==- Je le pensais.123- Ouaip.
La perturbation est faible (dans un exemple simple), mais je toujours le remarque.
Mettre la valeur en premier peut être une bonne idée si vous voulez pour attirer l'attention dessus, par ex. if (LAUNCH_NUKES == cmd). Ce n'est normalement pas l'intention.
Nocif? Non, cela fonctionne de toute façon.
Mauvaise pratique? Discutable, au mieux. C'est une programmation défensive simple.
Vaut-il la peine de dormir? Non.
Il s'agit essentiellement de flaimbait.
Non, cela ne fait pas plus de mal que de bien. Facile.
Plus de mots?
Argument du compilateur? Euh, peut-être - ne faites pas trop confiance au complice pour vous sauver de vous-même.
"Tu ne devrais pas oublier" - enfin duh - non bien sûr que tu ne devrais pas en attendant je suis fatigué, j'ai codé toute la journée j'ai dû utiliser deux langues différentes et parfois, parfois, étant humain, je fais une erreur.
Le point de ce genre de comportement est que sa défensive, ce n'est pas là parce que vous vous attendez à faire plus d'erreurs que vous avez d'assurance parce que vous vous attendez à planter ... mais si vous faites son Nice pour être couvert.
Difficile à lire? Vous vous plaignez qu'un programmeur décent devrait avoir == câblé (ce qui fait toutes sortes de mauvaises hypothèses) mais que le même programmeur décent ne peut pas lire la valeur 0 == ??
Ne fait pas de mal, a des avantages potentiels, question stupide, laissez les autres le faire s'ils le souhaitent et passez à autre chose.
Je ne dirais pas que c'est mal, mais c'est désagréable. Donc non, je ne dirais pas que c'est le cas.
Je n'ai jamais senti que le tout 'et si j'oublie un =?' jamais eu beaucoup de poids. Oui, vous pouvez faire une faute de frappe, mais nous faisons tous des fautes de frappe, il semble stupide de changer tout votre style de codage parce que vous avez peur de faire une erreur. Pourquoi ne pas mettre toutes vos variables et fonctions en minuscules sans ponctuation, car vous pourriez oublier de mettre en majuscule quelque chose ou oublier un trait de soulignement un jour?
Certaines personnes l'utilisent pour indiquer clairement ce que fait un conditionnel. Par exemple:
Voie 1:
FILE *fp;
fp = fopen("foo.txt", "w+");
if (fp == NULL) {
Voie 2:
FILE *fp;
if (NULL == (fp = fopen("foo.txt", "w+"))) {
Certaines personnes pensent que le deuxième exemple est plus concis, ou inverser les arguments illustre le point d'un test (conditionnel) avant le test lui-même.
En réalité, cela ne me dérange pas vraiment de toute façon. J'ai mes bêtes noires sur le style et le plus gros est l'incohérence. Donc, faites-le de la même manière, de manière cohérente et cela ne me dérangera pas de lire votre code.
Mélangez-le au point où il semble que six personnes différentes avec leur propre style distinctif ont travaillé dessus à la fois, je suis un peu ennuyé.
Pour moi, c'est un simple conditionnement. En tant que personne qui a appris (dans les années 90) le C et le C++, je m'y suis habitué et je l'utilise toujours, même si les raisons sont moins connues.
Une fois que vous êtes "conditionné" à regarder du côté gauche la "constante", cela devient une seconde nature.
Je l'utilise également uniquement pour l'équivalence (ou l'équivalence niée), pas pour plus/moins que.
Je suis entièrement d'accord avec la réponse de @ Wonko.
Le seul cas où je le trouve utile est celui où la partie variable du if est assez longue et voir les valeurs rend le code plus facile à lire. Les langages d'espaces de noms en pointillés en ont les meilleurs exemples.
Par exemple, quelque chose sur lequel j'ai travaillé avec l'authentification unique a eu une situation où vous pourriez avoir deux sessions simultanées si un certain type d'erreur s'est produit et a été récupéré d'une certaine manière, donc je dois ajouter un gestionnaire pour cela qui était à l'intérieur d'un si cela semblait quelque chose comme ça:
if (2 <= application.httpcontext.current.session["thenameofmysessiontoken"].items.count())
Certes, dans cet exemple, il existe d'autres façons de le faire, mais ce serait un cas où la version numéro un est potentiellement plus lisible.
Et pourtant, les erreurs se produisent. Et parfois, vous voulez une affectation dans un opérateur de boucle où vous pourriez sinon vérifier l'égalité, ou du moins c'est une pratique standard de l'utiliser.
Je le tiens un peu. Le conseil que j'ai suivi (peut-être de Code Complete) est de garder ce qui devrait être la valeur la plus basse à gauche dans les comparaisons. J'en discutais avec un collègue plus tôt et il pensait que c'était un peu fou, mais je m'y suis habitué.
Je dirais donc:
if ( 0 <= value )
Mais je dirais aussi:
if ( value <= 100 )
L'égalité, j'ai tendance à vérifier avec la variable de gauche, c'est juste plus lisible.