En effet, là ou PSR-0 apportait une solution technique, donc plus ou moins objective et discutable, à un problème d'interopérabilité, PSR-1 et surtout PSR-2 sont totalement subjectives, puisqu'elles définissent un certain nombre de règles concernant l'écriture du code.
Or, je ne connais rien de plus subjectif que les conventions de codage dans l'univers des développeurs, tout langage confondu, et d'ailleurs, les réactions ne se sont pas faites attendre et chacun essaye, en fonction de sa sensibilité et de ses préférences personnelles, d'expliquer pourquoi PSR-1 et PSR-2 sont illogiques et incohérentes.
De plus, j'ai beau chercher, je ne vois absolument pas la valeur ajoutée apportée par ces deux recommandations du point de vue de l'interopérabilité technique, alors que c'est pourtant l'objectif du PHP Framework Interoperability Group
d'apporter des solutions à ce niveau.
J'ajoute que PSR-0 a actuellement un effet relativement pervers sur la communauté des développeurs PHP, qui peut être résumé par si le projet ne suit pas PSR-0, c'est de la merde !
.
En effet, les développeurs et/ou les décideurs ont une nette tendance à oublier qu'il ne s'agit que d'une recommandation, et non d'une obligation, et que ce n'est pas parce qu'elle n'est pas mise en œuvre que le projet n'est pas intéressant.
PSR-0 est par nature un compromis, puisque son objectif est de favoriser l'interopérabilité, et en tant que tel, elle n'est pas la solution idéale dans tous les cas de figure.
Il peut donc être parfois plus que pertinent de ne pas la mettre en œuvre afin, par exemple, de gagner en performance ou en souplesse en adoptant une politique d'auto-chargement de classe différente de celle recommandée et plus adaptée au contexte d'utilisation.
J'ai donc très peur que la même logique soit appliquée à PSR-1 et PSR-2 et que des projets ne rencontrent pas le succès alors qu'ils sont pourtant très intéressants techniquement et/ou fonctionnellement, juste parce qu'ils ne suivent pas ces recommandations subjectives.
Qu'on ne s'y trompe pas, je sais, pour l'avoir déjà constaté, que tous les développeurs n'auront pas cette réaction, mais lorsque je lis que des décideurs ont dit au cours d'une table ronde au forum PHP que les développeurs n'ayant pas de code sur github ne les intéressent pas, je ne peux m'empêcher d'être tout de même un peu inquiet, car la logique est exactement la même.
Les conventions de codage ou le mécanisme d'auto-chargement de classe utilisés dans un projet n'ont strictement aucun rapport avec la qualité de ce dernier, tout comme le fait de ne pas diffuser du code, via github ou tout autre moyen, n'a strictement aucun rapport avec les capacités d'un développeur.
Il peut en effet y avoir moult raisons valables pour ne pas suivre PSR-0, PSR-1 ou PSR-2, tout comme il peut y avoir une palanquée de raisons valables pour qu'un développeur ne diffuse pas son code.
À la rigueur, cela peut être utilisé comme un indicateur, mais aucunement comme un gage de qualité, et baser une décision technique sur ce genre de constat est juste de la connerie à l'état pur.
Qu'on ne s'y trompe pas cependant, je ne suis pas du tout contre l'interopérabilité, et je pense que c'est même une très bonne idée.
Je trouve juste dommage qu'autant de temps et d'énergie soient dépensés par les membres du PHP Framework Interoperability Group
pour discuter de la pertinence du fait de mettre ou non des accolades à la ligne, alors qu'il y aurait bien mieux et bien plus intéressant à faire techniquement parlant pour favoriser l'interopérabilité.
10 réactions
1 De Da Scritch - 19/06/2012, 12:56
PSR-0, je trouve que cela alourdi tellement la lecture que cela peut rendre un projet un tantinet complexe et avec moult classes réutilisées à la limite de l'illisible sous les redites.
Mais je me trompe sûrement.
2 De Pierre Martin - 19/06/2012, 13:26
Bon article, tout comme celui d'Amaury ! Je rejoins également le camp :
PSR-1 -> bonne pratique (mais pas standard)
PSR-2 -> too much
Pour information le sujet a aussi éte débattu au sein de la core team de CakePHP et la conclusion est similaire : https://groups.google.com/d/topic/c...
3 De Amaury - 19/06/2012, 14:42
Bon article, Frédéric. Tu vas plus loin que moi dans la remise en question de l'utilité de PSR-2. Les normes d'écriture de code restent utiles ; il en existe déjà tellement qu'il n'y avait pas forcément besoin d'en créer un nouvelle, mais pourquoi pas. Moi je remets en question leurs choix, qui me semblent parfois inconsistants, parfois juste mauvais.
@Pierre : Oui, mais CakePHP faisait partie du groupe, j'ai quand même l'impression qu'il vont y passer tôt ou tard (et c'est ce que j'ai cru comprendre des discussion de leur core team).
4 De Guile - 19/06/2012, 16:20
N'y a-t-il pas eu une recherche d'intérêt particulier dans la PSR-2?
Je la trouve inconsistante avec elle-même, voire inconsistante dans une même règle (http://bit.ly/LBNmxU) en fonction d'un choix de présentation du développeur.
Non! Même si j'accueille chaleureusement l'initiative et le désir de standardiser la chose (et qui a au moins le mérite d'exister, de mettre à plat des règles, etc.), je dois avouer que la PSR-2 me dérange en cela qu'elle reflète les règles de certains, et pas de la majorité.
Y a-t-il l'un des participants qui travaille sur un parser de code PHP et qui a besoin de ce formatage? C'est ma principale question
5 De mageekguy - 19/06/2012, 16:56
@Guile : Le problème de la neutralité du groupe en question est encore un autre débat, mais on va dire que je crois encore suffisamment dans la nature humaine pour me laisser aller à penser que des intérêts particuliers n'ont pas pris le dessus sur l'intérêt général dans ce contexte… ou pas.
Bref, je n'ai aucune certitude, mais j'en connais qui te dirais que tout cela à ressemble beaucoup (trop ?) à ce qui est fait dans un framework à la mode actuellement.
6 De Da Scritch - 19/06/2012, 17:27
@mageekguy voilà, c'est ça le problème !
les framework sont plus là pour aider à utiliser de bonnes conventions de code que pour accélérer un éventuel travail préparatoire, et là, ce qui me dérange, c'est ce côté surverbose qui ressemble trop à un framework soupçonné.
7 De Pierre Martin - 19/06/2012, 17:31
@Amaury Oui, CakePHP a voté car faisant partie du groupe mais c'était un -1 : https://groups.google.com/d/msg/php...
D'ailleurs le compte final est bizarre et seuls "3" votes négatifs ont été recueillis https://groups.google.com/d/msg/php...
Le vote -1 de CakePHP (autant que je sache) est principalement lié à la présence du "code MUST use 4 spaces for indenting, not tabs" comme mentionné dans le sujet de discussion lié https://groups.google.com/d/topic/p... (Graham Weldon étant un membre de la core team de Cake)
Il est dommage que le "MUST" ait été utilisé dans ce "standard" au vu des discussions que l'on trouve dans le groupe à ce sujet.
Le principe d'un standard (aussi bête soit-il) est d'être suivi autant que possible donc il se peut que sur le moyen terme les projets qui n'y adhérent pas s'y tournent quand même, mais pour le coup je pense que cela prendra du temps, surtout avec la séparation PSR-1 / PSR-2
8 De francoism - 21/06/2012, 23:48
Je te rejoins sur le caractère scatologique de PSR-1 et PSR-2.
Le mélange de la technique (charger une classe) de l' "esthétique" (mise en forme du code et règles d'écriture) c'est comme si on disait qu'un mur de parpaing doit mesurer 2m32 et être peint en blanc.
Il semble que l'objectif de ces standards ait été un peu élargi en cours de route.
9 De ling - 08/10/2012, 08:49
En quoi la norme PSR-0 est-elle mieux que la convention de nommage Pear ?
Personnellement, j'aime bien la convention Pear, elle apporte plusieurs avantages :
- on voit directement le chemin complet de la classe, sans ambiguité
- le underscore c'est plus facile à taper que le antislash
- pas besoin de taper des mots-clés spéciaux use et namespace
Ensuite pour l'interopérabilité d'autoloader, vu comment l'autoloader généré par composer est fait, autant créer un autoloader manuel qui ressemble à cela :
//
//
// application/vendor/myautoloader.php
define('FS_VENDOR_DIR', DIR);
function myAutoloader($class) {
}
spl_autoload_register('myAutoloader', true, false);
//
//
//
et ajouter les entrées au fur et à mesure qu'on ajoute des nouvelles librairies à son application.
Donc je pourrais très bien inventer une norme qui s'appellerait QTN-0, et qui dirait que toutes les classes devraient utiliser la convention Pear. Au niveau de l'autoloader, c'est simplement le code ci-dessus ( et non pas le code complexe de l'autoloader généré par composer ), avec pour seule contrainte que le développeur ajoute un elseif à la fonction myAutoloader chaque fois qu'il veut intégrer une nouvelle librairie compatible QTN-0 à son projet ( et normalement, on ajoute pas des librairies tous les 4 matins ).
C'est pas plus simple comme ça ?
Dîtes-moi que je me trompe si je me trompe ?
10 De programaths - 26/04/2013, 12:56
@ling : C'est sur que
$a=new Vendor1_Http_Commons_Logging_SimpleFactory::create();
Est super digest. En tout cas mieux que:
use Vendor1\Http\Commons\Logging\SimpleFactory as LogF;
$a=LogF::create();
Je pense qu'ils devraient également changer les JSR pour enlever les namespaces/imports, c'est tellement pratique les '_'.