Si vous êtes versés dans le monde PHP, il y a quelques chances que vous ayez entendu parler de la norme PSR-0. Par contre, les normes PSR-1 et PSR-2 sont plus récentes, et de fait moins connues.
Ces normes sont définies par le « PHP Framework Interoperability Group » (FIG en abrégé), un groupe d’acteurs connus du monde PHP, contributeurs de frameworks, ORM et bibliothèques parmi les plus connus. Tout ce petit monde s’est réuni pour tenter de définir un ensemble de règles communes, afin de faciliter l’utilisation de différentes briques logicielles écrites en PHP.
L’effort est louable. La norme PSR-0 était absolument nécessaire, mais correspondait plutôt à la normalisation d’une bonne pratique répandue. La norme PSR-1 me semble personnellement pleine de bon sens.
Par contre, quand j’ai lu le contenu de la norme PSR-2, je me suis dit qu’ils avaient fait fausse route. Je sais bien qu’il faut parfois faire certains choix. Mais après avoir exposé les choses à mes développeurs, je me suis décidé à écrire un article sur le sujet.
PSR-0
La norme PSR-0 a pour but de faciliter le chargement automatique d’objets (aussi connu sous le nom d’autoload), par la mise en place d’espaces de nommage correspondant aux arborescences de fichiers sur disque. Le tout est très cohérent et très utile.
Comme je le disais plus haut, PSR-0 formalise une bonne pratique qui était déjà assez répandue.
PSR-1
La norme PSR-1 se repose sur PSR-0, et y ajoute quelques détails qui ont leur importance :
- Seuls les tags PHP <?php et <?= sont acceptés.
- Le code PHP doit être encodé en UTF-8.
- Les fichiers PHP peuvent contenir de la déclaration de symboles ou produire des écritures, mais pas les deux à la fois.
- Les noms de classes doivent être écrits en StudlyCaps.
- Les constantes s’écrivent en majuscule.
- Les méthodes s’écrivent en camelCase.
Encore une fois, tout cela n’est que du bon sens, et était déjà largement utilisé.
La seule chose qui manque, à mon avis, concerne les attributs de classe : leur écriture est volontairement laissée à l’appréciation de chacun. J’aurais personnellement préféré les normaliser en camelCase.
PSR-2
PSR-2 est une norme qui concerne le style d’écriture du code. Je vous laisse lire son contenu, mais moi ça m’a fait le même effet qu’à Brian Moon, qui a écrit un très bon article sur le sujet. Je vous invite aussi à lire son article, mais tout se résume avec une image :
Je trouve cette image savoureuse. C’est tellement vrai, non ? 🙂
Bon, mais pourquoi elle me défrise, cette norme PSR-2 ? Contrairement à ce que dit Brian Moon dans son article, je ne pense pas qu’il soit complètement vain de vouloir encore normaliser le style d’écriture du code ; c’est une chose importante, qui mérite qu’on s’y attarde. C’est juste que je pense sincèrement qu’ils auraient pu faire des choix plus judicieux.
En l’occurrence, voici les points qui me dérangent :
- L’indentation du code se faire avec 4 espaces, pas avec des indentations.
- Les objets et les méthodes ont leur accolade ouvrante sur la ligne d’après.
- Les structures de contrôle ont leur accolade ouvrante sur la même ligne.
- Sur les méthodes, le mot-clé static doit être utilisé après la visibilité.
Je vais revenir sur les deux premiers points.
Je déteste la non-consistance entre le deuxième point et le troisième. Pourquoi l’accolade ouvrante n’est pas toujours sur la même ligne (ou, à la limite, pourquoi y serait-elle jamais) ? À mon sens, ce n’est pas cohérent ; et j’ai du mal à voir la logique qui peut conduire à ce choix. On peut argumenter que les objets et les méthodes sont « spéciaux », qu’ils sont différents d’un if ou d’un while… mais je répondrais “Et alors ?”.
Pour le dernier point, c’est encore un problème de consistance. La norme PSR-2 dit que tous les attributs et toutes les méthodes doivent avoir une visibilité explicitement déclarée ; c’est une bonne chose. Elle dit aussi que les mots-clés abstract et final doivent être placés avant la visibilité. Je pense que c’est aussi une bonne chose ; quand on lit du code, le fait qu’une méthode soit abstraite ou finale est une information plus importante que sa visibilité ; cela a (encore) plus d’effet sur la manière dont on va l’appréhender et l’utiliser.
Mais de la même manière, je considère que le fait qu’une méthode soit statique est plus important que sa visibilité. Suivant qu’une méthode soit statique ou non, on ne l’utilisera pas du tout de la même manière. Donc il me semble logique que cette information soit placée avant la visibilité.
J’ai du mal à comprendre l’origine de cette inconsistance entre abstract, final et static. Et, entre-nous, j’ai un peu l’impression que la réponse est “Parce que c’est l’habitude en Java”…
Un peu d’histoire des normes
Je vais maintenant revenir sur les deux premier points : l’indentation à 4 espaces et les accolades sur une ligne seule.
Pour expliquer ce choix, il faut revenir en arrière et faire un petit historique des normes de codage. Vous m’excuserez, il est forcément incomplet, mais mon but est d’illustrer les deux grands types de norme qui existent.
Les GNU Coding Standards réclament l’indentation sur 2 espaces, avec les accolades à la ligne. Dans un style qui peut sembler particulier à certains, ce standard demande à indenter les accolades, ainsi que leur contenu. Ce qui donne ce genre de choses :
int
ma_fonction(int param1, int param2)
{
if (param1 < 0)
return param2;
else
{
while (param1--)
{
printf("Loop : %d\n", param1);
param2++;
}
return param2;
}
}
(ne cherchez pas à comprendre le code, j’ai écrit n’importe quoi)
Maintenant, intéressons-nous au Linux Kernel Coding Style. Dans le style provocateur qui caractérisait Linus Torvalds dans sa jeunesse, il y est écrit qu’il faut imprimer la norme GNU, ne pas la lire, et la brûler. Bref, la norme Linux est bien différente : l’indentation se fait avec des tabulations (dont la largeur d’affichage est réglée à 8 caractères) et les accolades sont sur la même ligne. Bizarrement, Linus considère lui aussi que les fonctions sont spéciales, et donc nécessitent d’avoir leur accolade à la ligne…
Bref, le résultat ressemble à ça :
int ma_fonction(int param1, int param2)
{
if (param1 < 0)
return param2;
else {
while (param1--) {
printf("Loop : %d\n", param1);
param2++;
}
return param2;
}
}
Ça a un look légèrement différent, hein ?
Si on prend un peu de hauteur (intellectuellement parlant), ces deux normes utilisent des moyens différents pour atteindre le même but : améliorer la lisibilité du code en séparant visuellement les différents niveaux d’imbrication.
Pour le GNU, cela se fait en ajoutant de l’espace vertical (les accolades ouvrantes seules sur une ligne), ce qui permet d’utiliser moins d’espace horizontal.
Pour Linus, cela se fait en ajoutant de l’espace horizontal, ce qui permet d’être moins gourmant verticalement.
En fait, on peut remarquer un truc : Ceux qui utilisent Emacs utilisent la norme GNU, ceux qui utilisent vi/vim utilisent la norme Linux. Je le sais pour être passé de l’un à l’autre durant ma carrière. Ça se fait naturellement ; par défaut, indenter avec des espaces est chiant avec vi, indenter avec des tabulations n’est pas très pratique avec emacs.
Aucune coïncidence là-dedans : Emacs est un projet GNU ; Linus utilise vi.
Donc, dans ces deux grandes familles, le FIG a plus-ou-moins choisi la voie donnée par le GNU. On peut juste remarquer que mélanger un faible espacement horizontal (indentation sur 4 espaces) avec un faible espacement vertical (l’accolade ouvrante est sur la même ligne que sa structure de contrôle) est une hérésie ; c’est la double-peine, et on fini par avoir du code franchement pas facile à lire. Autant rester sur un choix clair : soit on sépare verticalement, soit on sépare horizontalement.
Comme je l’ai déjà dit, l’important avec les normes de codage, c’est d’en choisir une et de s’y tenir. Alors pourquoi est-ce que je pense que la philosophie de la norme Linux est meilleure que celle de GNU ?
Relisez ce que j’ai écrit plus haut. GNU => consomme de l’espace vertical. Linux => consomme de l’espace horizontal. Quelle est la forme de nos écrans ? Eh oui, on a de l’espace à gogo en largeur, par contre c’est en hauteur que l’espace est compté.
Voilà pourquoi je préfère écrire du code dont les blocs sont clairement séparés par des belles tabulations. Je cherche à économiser l’espace vertical plus que l’espace horizontal.
Pas vous ?
Au fait
Je rappelle toutefois que toute cette longue déblatération est un peu inutile : Il existe des plugins (pour Eclipse, par exemple) permettant de modifier la norme d’écriture d’un fichier de code… Mais autant faire les choses proprement dès le début.
Sinon, la norme PSR-2 apporte quand même des indications qui me semblent pleines de bon sens. Un espace entre les structures de contrôle et leur parenthèse ouvrante. Pas d’espace après une parenthèse ouvrante, ni avant une parenthèse fermante. Pas d’espace entre le nom d’une fonction et sa parenthèse ouvrante.
Merci pour cet article bien documenté. Je ne suis pas tout à fait d’accord sur le coup du Emacs / Vim car un
:set expandtab» sous Vim transforme les tabulations en espaces, il n’est donc à mon sens pas plus difficile d’indenter avec des espaces que des tabulations en utilisant cet éditeur. C’est un détail, merci beaucoup pour la synthèse des PSR et j’abonde dans le sens de la conclusion : les dev PHP singent (une fois de plus) les pratiques du monde Java.Perso j’aime bien le CS de GNU car je trouve les blocs de code plus lisibles et même si ça m’obligeait à scroller, la bonne pratique d’avoir des méthodes qui ne font pas plus d’un écran de haut prenait tout son sens 😉
Pour ma part une norme qui vise à standardiser le style d’écriture de code n’a pas lieu d’être. La « beauté » du code c’est tellement subjectif qu’il vaut mieux laisser chacun gérer comme il l’entends.
Après libre à chaque entreprise / groupe de travail de créer une charte qui satisfait le plus grand monde.
A la limite que des recommandations existent pour les grands projets open source peut être un plus.
Je sais par exemple que chez nous on est allergique aux accolades sur la même ligne que la déclaration et donc tout le monde code avec l’accolade en dessous.
Idem pour les indentations , selon le système, l’ide ou que sais je encore on peut avoir ses préférences.
C’est un peu comme les extrémistes qui continuent de coder sous VI avec un 14″ cathodique et qui essaie de t’imposer 72 ou 80 char par ligne. Très bien pour eux mais moi sur mon2x 22″ 16/9 y se trouve que j’ai de la place et que tous mes collègue on là même config. Du coup quand un jeune stagiaire un peu trop présomptueux nous fait savoir que la ligne 212 fait 84 char et que c’est pas bien, ça nous fait bien rire ^^
Consistance ou pas… J’ai envie de dire, « et alors ? »
Le principal c’est qu’on prenne chacun le même standard. Ton interprétation est personnelle, avec de bons arguments, mais d’autres auront un avis contraire avec des arguments pas moins bons.
Alors, on admet que le FIG est compétent pour fixer la norme, et on l’applique non ? 😉
@greg : Oui, je sais qu’on peut faire faire ce qu’on veut à vi. C’est pour ça que je parlais du comportement par défaut des éditeurs. Sincèrement, la différence GNU/Linux est directement liées à Emacs/vi ; ce n’est pas qu’une coïncidence.
@Grunk : Justement, c’est parce qu’on a maintenant des écrans 24 pouces 16/9ème, qu’il me semble plus logique de consommer de la place en largeur plutôt qu’en hauteur.
@webaaz : Je suis d’accord pour dire que l’important est de prendre un standard et de s’y conformer (d’ailleurs, l’argument de Brian Moon est assez bon : pourquoi ne pas continuer à utiliser la norme PEAR ? cf. l’image XKCD)
Je pense bien qu’on peut me présenter de très bons arguments contraires aux miens. Je suis même ouvert à ce qu’on me fasse changer d’avis 🙂
Par contre, je reste sur l’idée qu’une norme doit être consistante et cohérente. C’est déjà difficile de faire comprendre à certains développeurs l’utilité d’une norme, ça devient impossible si c’est parfois comme-ci, parfois comme-ça.
J’étais parti pour te répondre, ou plutôt ajouter ma pierre au débat sous un angle légèrement différent, mais en écrivant mon commentaire, je me suis rendu compte qu’il serait bien mieux sous la forme d’un billet : http://blog.mageekbox.net/?post/2012/06/19/À-propos-de-PSR-0%2C-PSR-1-et-PSR-2
Hello,
Certaines normes sont purement arbitraire (je trouve ceci : plus lisible, plus joli, c’est mon habitude, …), d’autres techniques (espace vs tabs : certains outils de comparaison ont du mal…) ou encore de confort (par exemple le gain de place en hauteur) mais l’essentiel est effectivement que l’on s’y tienne.
Perso je pense que la norme psr-0 va être adopter par beaucoup, la psr-1 par un nombre un peu plus restreint, par contre la psr-2 être trop directive et touche a un sujet qui est souvent touchy… pour moi risque juste d’être adopté par certains et puis c’est tout…
@Grummfy : Je suis d’accord avec toi. Le taux d’adoption va chuter à mesure que la norme PSR s’éloigne de l’interopérabilité technique pour s’intéresser à des notions plus subjectives. Je ne sais même pas si tous les acteurs du FIG (phpBB, PEAR, Propel, Joomla, Drupal, CakePHP, Symfony, eZ Publish, Zend Framwork, …) vont migrer l’intégralité de leur code de manière à respecter les normes PSR-1 et PSR-2.
Il n’empêche, j’ai du mal à me faire un avis complètement tranché. Avoir du code qui respecte la même norme, cela réduit la charge cognitive nécessaire à sa lecture. C’est d’ailleurs l’un des arguments mis en avant par les utilisateurs du langage Python, dont la syntaxe impose peu ou prou le style d’écriture.
Mais, d’un autre côté, si je voulais qu’on m’impose une norme arbitraire, je coderais en Python…
Donc, mon avis, c’est que :
– Il existait déjà un paquet de normes, il n’y avait pas forcément besoin d’en établir une nouvelle.
– Si c’était si nécessaire que ça, je pense que leurs choix étaient mauvais (c’est mon avis personnel, je l’explique dans l’article mais je ne cherche pas à convaincre qui que ce soit).
– On verra déjà si tous les membres du FIG se plient à leurs propres normes. S’il le font, peut-être que ça fera boule de neige ; en attendant, c’est juste une norme de plus, ni la première, ni la dernière.
En même temps, coder avec un écran qui n’est pas orientable à la verticale, c’est une drôle d’idée.
@plopplop : Vu la taille de nos écrans aujourd’hui, il faudrait se casser le cou pour lever le regard tout en haut ! 😀
Ma préférence va aux tabulations, qui permettent à chacun de définir le nombre d’espaces correspondants dans son IDE.
Perso 1 tabulation = 4 espaces, mais d’autres peuvent définir 2 ou 8 selon leurs désirs.
@Jean : Ah, ça c’est l’erreur habituelle, qui conduit à des erreurs d’affichage indémerdables.
La convention veut que les tabulations soient affichées sur 8 caractères de large ; c’est le seul moyen pour que les indentations « fines » soient respectées. Par exemple lorsqu’il faut aligner des choses qui ne sont pas calées sur des tabulations.
Personnellement, je trouve qu’il y a au contraire une certaine logique dans la position de du mot clé static.
Je différencie ces mots clé en 3 catégories que je classerais par ordre de priorité :
– Ce que vous devez ou ne devez pas implémenter (abstract, final)
– Ce que vous pouvez ou ne pouvez pas appeler (public, protected, private)
– Comment est ce qu’on l’appeler (contexte objet ou statique)
Lors de la lecture d’une class, il me parait donc plus important de savoir si j’ai le droit d’utiliser une méthode (ou une propriété) avant de savoir comment l’utiliser (objet ou statique)
Je ne suis pas d’accord avec les certains arguments dans les commentaires sur la largeur d’écran. D’une part, le cou de l’être humain permet aussi bien de regarder à gauche et a droite, qu’en haut et en bas. Se casse le coup pour regarder un écran en position vertical reviendra à se faire un torticolis en regardant un écran horizontal. Blague à part 😉 Je préfère utiliser la largeur de mon écran pour mettre d’autres applications. Ou dans le cas de doubles écrans de mettre côte à côte deux fenêtre de code plus des outils de navigation dans le code (ou explorateur de variable dans la cas de débogage). Du coup mon espace de lecture sur un 1920×19080 n’est guerre plus large que sur mon vieux CRT 15″.
En revanches, pour les accolade je ne sais pas trop d’où vient cette différence il faut peut être regarder du côté de l’obligation de la présence des accolades sur les objet et méthodes et le côté optionnel sur les structures de contrôle.
Mais comme vous l’avez dis a de nombreuse reprise, tout cela est subjectif et le plus important est que toute l’équipe soit d’accord et l’applique.
@Amaury: dans ce cas, j’indente en tabulation pour aller au niveau de la fonction, puis je décale avec des espaces. Comme pour les commentaires phpdoc, ou je me positionne avec des tabs, je tape le /**, puis je met en forme avec des espaces.
Cela me semble le meilleur compromis pour que tout le monde soit content (personnellement travailler avec un décalage de 2 espaces m’horripile, alors que pour d’autres c’est l’inverse, or il faut bien travailler ensemble)
@Jean : Mouais, c’est pas idiot.
Perso je trouve que le mieux est d’avoir une convention où on se sent bien et de rester cohérent.
Personne n’est obligé de respecter la norme PSR-2
Tien je trouve cela bizarre, s’ils aiment la convention Java, pourquoi le mot-clé final doit se trouver avant la visibilité car je pense qu’en Java c’est l’inverse ref: http://en.wikipedia.org/wiki/Final_(Java)
Et pour une méthode final et static, c’est quel mot clé qui doit être le premier (perso je dirais static mais je ne sais pas si c’est le cas pour PSR-2).
Je suis totalement d’accord avec @Jérémy concernant la position des mots clés :
En lisant cette phrase, ça m’a paru logique car avant de savoir comment l’utiliser, cela parait plus important de savoir si tu peux l’utiliser ou pas dans ton contexte.
Ainsi : « abstract » et « final » vont t’orienter dans le contexte d’utilisation ; « public », « protected » et « private » vont te donner l’étendu de son utilisation et enfin « static » de te dire comment l’utiliser.
En ce qui concerne les accolades, je vais m’avancer dans quelque chose mais c’est absolument pas vérifié du tout… Juste une idée : je pense qu’il est pertinent de différencier la structure de la classe de son contenu. Ainsi, visuellement, l’œil se concentre plus aisément sur le contenu d’une méthode lorsque les accolades sont sur la même ligne. Je veux dire par là qu’il n’y a pas de « cassure » visuelle.
Autrement, n’y aurait-il pas aussi un lien entre les parsers de code ainsi que les informations relatives aux erreurs ? Je ne sais pas trop comment PHP récupère la ligne de code en interne quand il construit une trace d’exception mais peut-être que placer différemment les accolades peut aider. A fouiller…
Enfin, je suis une fois encore d’accord avec @Jérémy sur l’indentation et je rajouterais ceci : il me semble que la molette de ta souris scroll verticalement par défaut non ? De plus, ton éditeur scroll aussi verticalement quand tu accède aux symbols… Puis, en SSH, c’est carrément une plaie de devoir se déplacer horizontalement parce que chaque indentation est trop large…
Je trouve cela bien qu’il y ait une « norme » sur le style d’écriture (même si je ne suis pas tout à fait d’accord avec tout les points).
Le PSR c’est avant tout pour le travail en équipe.
Hello,
En deux mots (suis en retard ! ;)) : à mon humble avis ces différentes normes de codage n’ont pas tant vocation à améliorer la lisibilité du code (aucune règle en la matière ne saurait être universellement reconnue) qu’à assurer la pertinence des diff entre deux révisions d’un même fichier.
Idéalement on devrait s’assurer que tout code déposé Dans un système de contrôle de version soit automatiquement formaté de façon constante.
G
Merci.
J’ai enfin des arguments qui me parlent pour choisir entre l’accolade ouvrante sur la ligne d’après ou sur la même ligne.
L’indentation par des espaces me faisant pleurer (j’exagère, disons juste que je n’y adhère pas), je vais dorénavant poursuivre la logique d’économie d’espace vertical et utiliser l’accolade ouvrante sur la même ligne.
Je suis entièrement d’accord avec l’article.
Mais en plus je rejoins Jean sur le fait que tout l’intérêt d’une tabulation c’est qu’elle est modulable (chacun l’affiche comme il veut). Je ne voit pas où est le problème avec l’indentation « fine », on reviens à la ligne et puis c’est tout. De toute façon un bon IDE va s’occuper de caler l’affichage sans rajouter des caractères inutiles.
De plus 1 tabulation, c’est 1 caractère. 4 espaces… c’est 4 caractères, donc 4 fois plus de place (c’est peut-être négligeable, mais ça fait fait encore un argument en faveur des tabulations, et toujours 0 pour les espaces).
Et quand au fait que les tabulations font dépasser le code de l’écran :
* 1 : c’est quand même très très rare. Personnellement je m’arrange pour que mon code fasse moins de 150 caractères sur une même ligne.
* 2 : encore une fois, un bon IDE va couper automatiquement le code pour l’afficher indenté à la ligne suivante sans rajouter de caractères inutiles.
* 3 : on peut toujours configurer la tabulation pour s’afficher en 1, 2, ou 3 espaces si on veut.
(Pour info, j’utilise NetBeans)
@mysterty Mais on s’en fiche des espaces ou des tabulations. L’intérêt n’est pas là. Ce ne sont que des préconisations. Fait en ce que tu veux. Personne n’a raison ou tort.
Lis donc le billet de @mwop http://t.co/62nOmoeN4c sur le sujet 🙂
J’adore ces débats sur la visibilité,
mais dans la vraie vie je préfère que le travail soit fait.
Le coding style est très dépendant de l’outillage et de
la culture d’entreprise.
Je dépense beaucoup d’espace vertical pour séparer
sémantiquement mes idées, en c# j’abuse des régions,
ce qui a le don d’irriter mes collègues qui ne documentent
pas leur code, cependant ils sont heureux de pouvoir comprendre
et reprendre mon code aisément.
Tout est une question d’objectif :
Si il faut être rigoureux et contribuer à un projet en passant plus
de temps à relire son code , ou si il faut être On Time dans une
startup.
Le coding style est plus une affaire d’outil de développement
qu’une réelle question d’entreprise.
Je ne saurai dire si une accolade en début de fonction
function blabla($params) {
ou une accolade sur la ligne suivante
function blabla($params)
{
pourra améliorer la rentabilité de l’entreprise .
Tant que les humains s’y retrouvent…
Je laisse toute la latitude à mon équipe pour
le coding style, au bout de 4 ans des règles tacites
ce sont créées et tout le monde est heureux.
@julien : Certes. Chacun fait comme il le sent.
Mais tu dis toi-même que des règles se crées à l’usage. Ce qui veut bien dire que les développeurs se sentent naturellement plus à l’aise quand certaines règles sont suivies. Autant les définir en amont, pour ne pas se retrouver à avoir du code qui reflète les tâtonnements de l’équipe au fil des années.
On ne peut pas nier que lorsque le code respecte une norme d’écriture commune, on passe moins de temps à passer d’un bout de code à un autre ; la charge cognitive est plus faible.
Et lorsqu’une norme est bien faite, elle devient naturelle pour les développeurs qui l’utilisent. Cela devient un « non-sujet », et c’est très bien ainsi.
Avant j’utilisais Notepad++ sans me soucier des espaces Vs indentations.
Et puis j’ai voulu participer à un projet open source et là ce fut l’horreur. Il utilisait des indentations sous Linux et moi sous Windows du coût toute la présentation était foutue et demandait plus de travail pour les membres qui devait valider les merges.
A partir de ce moment j’ai toujours afficher les caracteres masqués afin de voir si le projet utilsait des espaces ou des indentations.
A titre personel, je préfère des espaces, et même si je suis passé sur un véritable IDE, même les editeurs de textes gère l’un et l’autre de maniere totalement transparente.
Donc je m’adapte en fonction du projet sur lequel je bosse s’il ne m’appartient pas sans faire tout une histoire. Quitte a repasser en tabulation juste avant de commit & merge.
Et je ne peste pas parce qu’un dev ne partage pas mon avis, c’est franchement le cadet de mes soucis…
PHP a acquis ses lettres de noblesses : Il est devenu aussi compliqué à utiliser que les autres langages plus « pro ».
PHP est arrivé à maturité ; je veux dire qu’il est mur comme un fruit qui va tomber de son arbre.
Les dev expérimentés PHP peuvent redresser les épaules.
… Pas pour longtemps ; PHP est un langage pour le web mais qui est hérité du PERL et qui ressemble de plus en plus à Java.
Or un vrai langage conçu réellement pour le web va émerger. c’est inéluctable.
Ce langage sera simple et suivra le même chemin que PHP. Ce ne son que des cycles.
Paroles d’un vieux shnock qui a 8 langages a son actif.
Tout à fait d’accord. Cf. ma conclusion dans l’article consacré à la simplicité et à la syntaxe des langages de programmation. On assiste sans arrêt à des cycles de simplification et de complexification, dans un éternel recommencement…
Ce poste date mais je suis tombé dessus par hasard même si je suis plus ou moins d’accords avec l’article et que je code en norme PSR-4 actuellement et sur certain projet nous sommes en PSR-2 je tiens à apporté un éclaircissement sur l’espacement en verticalité ou horizontalité.
Vous préférez l’espacement horizontal au point de vue de la largeur des écrans (wildscreen) ce qui peut être louable, MAIS !
Dans une moindre mesure lorsque vous vous retrouvez avec beaucoup de code notamment aujourd’hui, il est d’une, important de limiter le nombre de caractère sur une ligne à environ 120 caractères.
Et de deux, et de loin la plus importante, il est plus « ergonomique » de lire un code ou même un texte sur sa verticalité que sur son horizontalité et il en va de même pour un code.
Il est plus facile de scroller de haut en bas plutôt que de gauche à droite.
Lorsque j’ai instauré dans une entreprise de meilleurs pratiques de codage car je suis profondément attaché à un code propre et bien structuré plutôt qu’un code comme je le nomme « Un Code Egoïste » qui se destine en fait à un usage unique et personnel propre au développeur qui l’a pondu.
Le résultat était sans appelle, tous les développeurs qui sont passés sur mon code ont eu une grande facilité à le lire, le comprendre et l’étendre (où le déstructurer par moment) tant dis que pour les autres ce fut un calvaire et donc source de bug dans l’évolution des applications dont j’ai dû corriger qui plus est, tant sur le javascript que sur le php.
L’entreprise où je suis était habitué depuis plus de 10 ans à coder comme des porcs concrètement sans se tenir informer des pratiques, des évolutions et du POURQUOI (pas de veille techno en gros).
Au fur et à mesure que je debugais leur code et que j’expliquais pourquoi il ne fallait pas faire comme ça ou comme ceci, j’ai vue leur visage dépité ainsi que leur arrogance de premier abord (lorsqu’un nouveau intègre une entreprise dès fois) disparaître.
Je leur est bien dit que ce n’était pas une manière « personnelle » ni l’égo qui m’amenait à leur dicter fait comme ci pas comme ça. Mais bien dû à mes expériences passés ainsi que l’expériences provenant d’autres développeurs.
Moins évident, j’ai dû corriger tout le code html, css, javascript et php de mon bosse, moins évident lorsque vous êtes un employé et que vous vous retrouver à engueuler limite votre bosse car il est entrain de détruire une application pendant que vous vous corrigez toutes ses erreurs de structuration illogique.
J’ai essayé de ne pas être trop stricte au début car c’était comme un tsunami de pratique qui s’écrasé sur eux, j’ai eu l’impression d’être un dictateur du code à un moment tellement certains avaient peur de mal structurer leur code (lol), un peu embarrassant (quand je pense que des anciens supérieurs étaient plus stricte que je ne le suis ça fait bizarre).
Dans la norme PSR-4 l’accolade ouvrante concernant les class, méthode etc… se trouve sur la même ligne.
J’ai choisi d’instaurer plutôt ces accolades sur la ligne suivante pour plus de visibilité concernant l’encapsulation du code, par contre concernant les conditions et les boucles j’ai laissé libre aux codeurs tant qu’ils ne mettent pas des conditions ternaires PARTOUT !! ou bien des switch case car un préfère les conditions en switch case et l’autre n’aime que le ternaire.
Ce genre de pratique dénote plus une mauvaise connaissance du pourquoi existe-il des conditions ternaires et pourquoi existe-t-il des boucles et conditions de cette façon.
Au plaisir de vous lire.
Oui, on est bien d’accord. Les normes sont nécessaires, je n’ai jamais dit le contraire. Notamment pour réduire la charge cognitive nécessaire à un développeur pour relire le code d’un autre développeur. Il n’y a pas vraiment de « bonne » norme ; ce qu’une personne trouvera très propre, une autre la trouvera dégueulasse. Autre point, il faut penser à normer tout ce qui peut l’être (normer le PHP c’est bien, mais il faut aussi penser à écrire les requêtes SQL toujours de la même manière, par exemple).
Dans mon entreprise, la norme est clairement définie. D’ailleurs, je suis en train de mettre en place un programme qui va remettre les fichiers PHP à la norme automatiquement à chaque commit, un peu comme le langage Go qui remet les fichiers à la norme à chaque compilation (comme ça tous les codeurs Go utilisent la même norme, pas de question à se poser, c’est quand même puissant).
Je ne dis pas qu’il faut scroller horizontalement. Ce n’est pas pratique, c’est sûr. Mais on peut maintenant aller un peu plus loin que 120 colonnes tout en restant très lisible. Mais c’est un détail qui dépend de plein de paramètres (taille d’écran, éditeur de code utilisé, etc.).
Bonjour,
PSR-4 concerne l’autoload.
Cordialement