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é.