“If (if = 0 == value)…” ne fait-il pas plus de mal que de bien? [fermé]

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 mettais accidentellement '=' à la place?"). Pour moi, c'est comme quand un enfant descend les escaliers en comptant les pas à haute voix.

Quoi qu'il en soit, voici mes arguments contre:

• Cela perturbe le flux naturel de lecture du code du programme. Nous, les humains, disons "si la valeur est zéro" et non pas "si zéro est la valeur".
• Les compilateurs modernes vous avertissent lorsque vous avez une tâche dans votre condition, ou en fait si votre condition consiste uniquement en une tâche qui, oui, a l'air suspecte quand même.
• Vous ne devez pas oublier de mettre 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 la valeur est zéro, exécutez ce code, vous devez!"). Je pointe toujours ceux qui prétendent être "meilleurs" vers des outils tels que la charpie (1). Ce problème particulier a été résolu depuis la fin des années 70. La plupart des langues modernes ne compileront même pas une expression du même type if(x = 10), car elles 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.

C'est odieux parce que cela impose un impôt mental 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 la suivante:

• 123- et alors? information incomplète.
• == - Bon, 123 c'est 123, pourquoi le tester ...
• x- ok, c'est ce qui nous préoccupe. Ce n'est que maintenant que j'ai le contexte.
• Retournez à reconsidérer 123et pourquoi x y est comparé.

Quand je vois x == 123l'analyse mentale, c'est:

• x- Fournit le contexte, je sais de quoi il s'agit. Je peux choisir d'ignorer le reste. Sur la base du flux précédent, j'ai une bonne idée du pourquoi et de ce qui va arriver (et soyez surpris si c'est différent).
• == - J'ai pensé ainsi.
• 123 - Ouaip.

La perturbation est faible (dans un exemple simple), mais je le remarque toujours .

Mettre la valeur en premier peut être une bonne idée si vous souhaitez attirer l’attention, par exemple if (LAUNCH_NUKES == cmd). Normalement, ce n'est pas l'intention.

Nocif? Non, cela fonctionne dans les deux sens.

Mauvaise pratique? Discutable, au mieux. C'est une simple programmation défensive.

Vaut la peine de dormir? Nah.

Ceci est fondamentalement flaimbait.

Non, cela ne fait pas plus de mal que de bien. Facile.

Plus de mots?

Argument du compilateur? Euh, ish, peut-être - ne misez pas trop sur le complier pour vous sauver de vous-même.

"Tu ne devrais pas oublier" - bien duh - non bien sûr tu ne devrais pas entre temps je suis fatigué, j'ai codé toute la journée j'ai dû utiliser deux langues différentes et parfois, juste parfois, être humain, je le fais une erreur.

Le point essentiel de ce type de comportement est qu’il est défensif, il n’est pas là parce que vous vous attendez à faire des erreurs plus que vous n’avez une assurance parce que vous vous attendez à un crash ... mais si vous le faites, il est agréable d’ê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 0 == valeur ??

Ne pas nuire, a des avantages potentiels, question idiote, laisser les autres le faire s’ils le souhaitent et passer à autre chose.

Je n'appellerais pas ça du mal, mais c'est odieux. Donc non, je ne dirais pas que c'est le cas.

Je n'ai jamais pensé que l'ensemble "Et si j'oubliais un =?" jamais vraiment tenu beaucoup de poids. Oui, vous pouvez faire une faute de frappe, mais nous faisons tous des fautes de frappe, il semble idiot de changer tout votre style de codage parce que vous avez peur de vous tromper. Pourquoi ne pas définir toutes vos variables et fonctions en minuscules sans aucune ponctuation, car vous pourriez oublier de mettre quelque chose en majuscule ou un trait de soulignement un jour?

Certaines personnes l'utilisent pour expliquer clairement ce que fait une condition. 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 l'inversion des arguments illustre l'intérêt d'un test (conditionnel) avant le test lui-même.

En réalité, cela ne me dérange pas vraiment. J'ai un faible pour le style et le plus important 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 se soient travaillées en même temps, je suis un peu agacé.

Pour moi, c'est un conditionnement simple. En tant que personne qui a appris (dans les années 90) le C et le C ++, je m'y suis habituée et je l'utilise encore, même si les raisons en sont tirées.

Une fois que vous êtes "conditionné" à regarder le côté gauche pour la "constante", cela devient une seconde nature.

Je ne l'utilise également que pour l'équivalence (ou l'équivalence négative), pas pour supérieur / inférieur à.

Je suis complètement d'accord avec la réponse de W / @ Wonko.

Le cas dans lequel je trouve cela utile est celui où la partie variable du if est assez longue et voir les valeurs facilite la lecture du code. Les langages d'espace 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 pouviez avoir deux sessions simultanées si un certain type d'erreur se produisait et était récupéré d'une certaine manière. Je dois donc ajouter un gestionnaire à l'intérieur si quelque chose comme ça:

if (2 <= application.httpcontext.current.session["thenameofmysessiontoken"].items.count())

Certes, dans cet exemple, il existe d'autres moyens de le faire, mais il s'agirait d'un cas où la version avec le numéro premier serait 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 il est pratique courante de l’utiliser.

Je maintiens quelque chose. Le conseil que j’ai suivi (éventuellement de Code Complete) est de garder ce qui devrait être la valeur inférieure sur la gauche lors des comparaisons. Je discutais de cela avec un collègue un peu plus tôt et il pensait que c'était un peu fou mais je m'y suis habitué.

Alors je dirais:

if ( 0 <= value )

Mais je dirais aussi:

if ( value <= 100 )

Égalité Je vais plutôt vérifier avec la variable de gauche, elle est simplement plus lisible.