JeuWeb - Crée ton jeu par navigateur
Pourquoi "valeur" == $variable au lieu de $variable == "valeur" - Version imprimable

+- JeuWeb - Crée ton jeu par navigateur (https://jeuweb.org)
+-- Forum : Discussions, Aide, Ressources... (https://jeuweb.org/forumdisplay.php?fid=38)
+--- Forum : Programmation, infrastructure (https://jeuweb.org/forumdisplay.php?fid=51)
+--- Sujet : Pourquoi "valeur" == $variable au lieu de $variable == "valeur" (/showthread.php?tid=7725)



Pourquoi "valeur" == $variable au lieu de $variable == "valeur" - Patatruc - 20-11-2016

Comme précisé, je poste cette question bête pour meubler le silence, donc inutile d'y répondre, c'est comme vous voulez. Smile

Il n'y a pas si longtemps, je voyais assez souvent des programmes où les tests sont systématiquement construits sous cette forme :

Code :
if(constante == variable) ...

Par exemple :

Code :
if("TotoLeHéros" == nom_utilisateur) ...

Variante assez similaire : une variable solution (immuable une fois que le programme lui a affecté une valeur) est comparée avec une autre variable proposition dont la valeur change périodiquement -saisie utilisateur, par exemple- sous cette forme :

Code :
if(solution == proposition) ...

J'ai l'impression de voir moins souvent ce type d'écriture, peut-être que ça correspondait à une mode ? Une manière de se singulariser ?

Ca me perturbe pas mal, comme presque tout le monde j'ai toujours écrit dans le sens inverse (variable == valeur constante) qui me semble beaucoup plus naturel -pour ne pas dire "logique"- et bien plus lisible : je ne me pose pas une question sur l'élément constant, je me la pose sur l'élément variable.

C'est un peu comme si on posait la question "est-ce que 'Martin' est son nom ?" au lieu de dire "est-ce que son nom est 'Martin' ? ", et d'une manière générale comme si on inversait la position du sujet et celle de l'attribut en langage naturel.

Alors ma question c'est : y a-t-il une raison particulière de construire les tests sous cette forme ? Le faites-vous vous-même ? Me trompè-je en disant que ce n'est pas très naturel ni très lisible ? Ou alors pour vous ça n'a pas d'importance, c'est juste une question de goût ?

Voilà c'était ma question bête pour meubler le silence. Smile


RE: Question bête pour meubler le silence - Sephi-Chan - 20-11-2016

Cette forme permettait d'éviter un accident : l'oubli d'un signe égal. Exemple :


if($role = "admin"){ … }

Ce test est toujours évalué comme true, ce qui peut poser problème.


RE: Question bête pour meubler le silence - julp - 20-11-2016

Oui, écrire if ('bar' = $foo) (pour du PHP mais c'est applicable à bien d'autres) n'est pas valide donc lèvera une erreur ce qui permettra de voir immédiatement le soucis. Alors que if($foo = "bar") pourrait passer inaperçu et, dans l'exemple de Sephi, ce ne serait pas anodin si quelqu'un gagne ainsi des privilèges (une chaîne non-vide ni '0' étant une valeur vraie).

J'ai pris l'habitude de mette la valeur constante à gauche. Je trouve au contraire que c'est plus lisible sur des instructions à rallonge, ça met en évidence la comparaison et valeur de retour attendue (d'un appel) d'une fonction par exemple. Il y a des langages où un simple = est la comparaison (SQL par exemple) donc quand tu passes de l'un à l'autre, il peut être facile d'oublier un = en route.

Au final, c'est vraiment une question de goûts : les deux sont parfaitement valides, ça ne change pas le sens de l'instruction pour autant.


RE: Question bête pour meubler le silence - Xenos - 20-11-2016

Perso, je préfère la version "classique" du $a == 'b' car on compare rarement une variable à une constante, sauf dans le cas d'un switch (qui s'écrit en demandant la variable d'abord puis en listant ses valeurs dans les case). Le plus souvent, c'est $a == $b donc si on s'est reposé sur le trick "flip operand" pendant des années, on oubliera le second "=".

Les IDE marquent un warning sur les instructions if ($a = 'b'), ce qui évite de recourir à ce genre de trick pour éviter une simple étourderie de codeur.


RE: Question bête pour meubler le silence - Patatruc - 20-11-2016

(20-11-2016, 08:00 PM)Sephi-Chan a écrit : Cette forme permettait d'éviter un accident : l'oubli d'un signe égal.

Merci, je me disais bien qu'il y avait une raison concrète mais je n'avais pas pensé à ça.

Ca heurte trop la lecture pour moi, je préfère encore risquer l'erreur. Smile

Bon je ne suis pas déçu, c'était bien une question bête. J'en chercherai d'autres à l'occasion. Big Grin


RE: Question bête pour meubler le silence - niahoo - 21-11-2016

Franchement ça gène la lisibilité ? Perso je lis l'égalité comme un tout donc dans un sens ou dans l'autre ça change pas grand chose, mais j'aime bien la petite sécurité que ça apporte !

Après en ayant l'habitude de mettre trois signe '=' ça ne m'arrive jamais de faire cette erreur.


RE: Question bête pour meubler le silence - Xenos - 21-11-2016

Tant qu'à être dans le domaine, du coup, vous écrivez:
if (0 <= $value)
ou
if ($value >= 0)
?
Perso, la seconde.


RE: Question bête pour meubler le silence - niahoo - 21-11-2016

J'aime bien utiliser < et <=, et moins utiliser > et >=, donc si j'y pense j'ordonne de gauche à droite dans le sens des valeurs croissantes. Sinon comme toi.


RE: Question bête pour meubler le silence - Ter Rowan - 21-11-2016

je lis / j'écris comme Xenos (en français quoi, pas en yoda) mais c'est personnel, je me racontes une histoire quand je développe (et ouais... on peut faire du storytelling en développant)

évidemment c'est la même chose dans les deux sens d'un point de vue informatique donc l'écriture dans l'autre sens ne me gêne pas

Par contre < ou > j'essaie toujours de virer le "=" (dans une vieille croyance de performance, genre <= c est < || = donc deux conditions) du coup je suis plutôt "<" que ">=" et plutôt ">" que "<=" mais avec une priorité moindre que mon storytelling


RE: Question bête pour meubler le silence - niahoo - 21-11-2016

Un truc cool en Erlang/Elixir c'est que tu peux le faire en dehors d'un if, tu peux faire un match :

Code :
true = do_something_with_stuff(a, b, c)

Si ça match pas, tu génères automatiquement une erreur.