16-06-2009, 10:09 PM
(Modification du message : 16-06-2009, 10:12 PM par Sephi-Chan.)
Allwise, ce n'était que des exemples de syntaxes. Ne crois pas que ce goût du Ruby vient uniquement de sa syntaxe. En ce qui me concerne, je vois plutôt tout ça comme un jeu.
Plus concis car plus court : objet, point, attribut/méthode.
Plus lisible car moins verbeux : la flèche à la place du point, les guillemets (symbole très bruyant) qui entourent la clé.
Ensuite, concernant les clés, tu peux tout à fait utiliser une chaîne de caractère (ou n'importe quel objet qui implémente une méthode qui permet de calculer le symbole équivalent) en guise de clé. Mais l'utilisation des symboles (ces variables préfixées des deux points) est recommandée pour la performance.
En l'occurrence, comme on est amené à développer et donc se relire (et c'est encore plus vrai dans le travail en groupe), c'est plutôt pas mal que le langage fixe lui-même des règles.
En tout cas, la réputation de PHP comme langage sale vient bien de quelque part : on laisse plein de choix aux développeurs, donc forcément chacun y va de sa petite touche personnelle et au final, on a plus facilement tendance à lire du code crade. Par contre, je ne vois pas les avantages (pouvoir choisir ne fait ni partie des avantages, ni des inconvénients en ce qui me concerne).
Sephi-Chan
(16-06-2009, 09:31 PM)naholyr a écrit :Je pense pas être subjectif :(16-06-2009, 08:43 PM)Sephi-Chan a écrit : Tu noteras que user.prenom est plus lisible et concis que $user->prenom, de même que user[:prenom] par rapport à $user['prenom'].Ah.
Plus concis car plus court : objet, point, attribut/méthode.
Plus lisible car moins verbeux : la flèche à la place du point, les guillemets (symbole très bruyant) qui entourent la clé.
(16-06-2009, 09:31 PM)naholyr a écrit :Comme tu le dis, la bonne pratique va à l'utilisation des accolades, pourquoi ne pas le rendre obligatoire ? C'est comme ça qu'on a un code source plus lisible.Citation :En Ruby, la cohérence est de mise, on utilise toujours #{variable}. C'est ce genre de petits riens en ce qui concerne la cohérence qui font la lisibilité de Ruby.C'est une contrainte, en PHP on peut toujours utiliser les accolades autour d'une variable (c'est plutôt une bonne pratique d'ailleurs). L'inconvénient de PHP dans ce cas et de ne pas imposer une notation, mais de laisser le choix.
(16-06-2009, 09:31 PM)naholyr a écrit :Tu trouveras des gens pour s'amuser d'une portion de code monoligne dans tous les langages, il y a même des concours autour de ça. De là à se baser dessus pour critiquer la lisibilité d'un langage.Citation :PHP est un très mauvais élève à ce sujet (isset(), is_numeric(), etc.), c'est sa réputation de langage sale est méritée : il est plus facile de faire un code sale avec PHP qu'avec Ruby.Perso je n'ai toujours pas réussi à ne pas vomir devant des lignes de ruby manipulant fièrement des listes et des chaines de caractères avec des opérateurs ésotériques à base de caractères spéciaux. Les tableaux sont d'excellents exemples : plutôt que de faire un système de hash standard ou la clé est une variable, nooooon il fallait qu'ils rajoutent un caractère spécial (":"). Et c'est partout comme ça : c'est super de pouvoir faire trouze-mille choses en tapant :a->#~b! mais c'est impossible à relire
Ensuite, concernant les clés, tu peux tout à fait utiliser une chaîne de caractère (ou n'importe quel objet qui implémente une méthode qui permet de calculer le symbole équivalent) en guise de clé. Mais l'utilisation des symboles (ces variables préfixées des deux points) est recommandée pour la performance.
(16-06-2009, 09:31 PM)naholyr a écrit :Je parle de syntaxe : Ruby différencie syntaxiquement une variable locale d'une variable globale. C'est tout de même plus simple (et sémantique) que de passer par un tableau, non ?Citation :J'en profite également pour souligner qu'en PHP, on ne différencie pas une variable globale d'une variable locale. En Ruby, une variable globale est préfixée d'un symbole dollar. A nouveau : clarté du code oblige.De manière général, les globales c'est mal, et en PHP là encore rien n'interdit (au contraire, c'est une bonne pratique) d'utiliser $GLOBALS.
Là encore, liberté de choix versus choix unique.
(16-06-2009, 09:31 PM)naholyr a écrit : C'est pour ça que la dernière fois je ralais sur ces effets de mode et associait Mac à Ruby : il y a la même philosophie derrière, qui est "ne laissons aucun choix à l'utilisateur, tout en lui expliquant qu'au fond il a le choix, mais qu'on a déjà fait les meilleurs pour lui, il sera content". Et j'adhère pasJe comprends que tu n'adhères pas, mais c'est un parti pris qu'a fait le créateur du langage : si on aime cette philosophie (encore que dans le cas de Mac OS X, c'est différent puisque dessous, tu as une bonne part de FreeBSD plutôt personnalisable mais là n'est pas le débat), on choisit ce langage. Sinon, on en prend un autre.
En l'occurrence, comme on est amené à développer et donc se relire (et c'est encore plus vrai dans le travail en groupe), c'est plutôt pas mal que le langage fixe lui-même des règles.
(16-06-2009, 09:31 PM)naholyr a écrit : Cela dit, il y a plein d'autres langages entre les deux, qui sont moins permissifs, et moins "write only". On appréciera le fait que quasiment tout le monde ait cité Python dans ses messages (moi y compris) mais que personne ne l'utiliseJe n'ai pas vraiment accroché à Python car ça devient vite chiant à lire, comme ça fonctionne à l'indentation et qu'il n'y a pas de fermeture de bloc. Ça me va très bien dans des fichiers de vue Haml, mais pas dans du code métier.
En tout cas, la réputation de PHP comme langage sale vient bien de quelque part : on laisse plein de choix aux développeurs, donc forcément chacun y va de sa petite touche personnelle et au final, on a plus facilement tendance à lire du code crade. Par contre, je ne vois pas les avantages (pouvoir choisir ne fait ni partie des avantages, ni des inconvénients en ce qui me concerne).
Sephi-Chan