PSR-Hein?

Si vous êtes un développeur passionné de PHP, il est fort probable que vous ayez rencontré l'abréviation, PSR, qui signifie "PHP Standards Recommandation." Au moment d'écrire ces lignes, il y en a quatre: PSR-0 à PSR-3. Jetons un coup d'œil à ce qu'il en est et pourquoi vous devriez vous en préoccuper.


Une histoire brève

PHP n'a jamais vraiment eu de standard uniforme pour l'écriture de code. Ceux qui gèrent différentes bases de code consacrent du temps à écrire leurs propres conventions de dénomination et règles de style de codage. Certains de ces développeurs choisissent d'hériter d'une norme bien documentée, telle que PEAR ou Zend Framework; d'autres encore choisissent d'écrire les normes complètement à partir de zéro.


Le groupe d'interopérabilité du cadre

N'hésitez pas à ouvrir un nouveau sujet dans la liste de diffusion.

À la conférence php | tek de 2009, des représentants de différents projets ont discuté de leurs options de travail entre projets. Il n’est donc pas surprenant que le principal point de l’ordre du jour ait été de respecter un ensemble de normes..

Jusqu'à récemment, ils se présentaient sous le nom de "Groupe de normes PHP", mais ils exercent désormais leurs activités sous le nom de Framework Interoperability Group (FIG). Selon eux, les premiers n'ont pas décrit avec précision les intentions du groupe. Même si le nom de ce groupe fait explicitement référence à des frameworks, les développeurs représentant toutes sortes de projets ont été acceptés comme membres votants..

La FIG a l'intention d'héberger un échantillon de l'écosystème PHP, pas exclusivement les développeurs de framework. Par exemple, les frameworks Symfony, Lithium et CakePHP ont chacun un représentant en tant que membre votant, mais il en va de même pour PyroCMS, phpDocumentor et même Composer..

Les membres votants peuvent commencer ou participer à des votes, cependant, n'importe qui (y compris vous!) Peut devenir membre de la communauté PHP-FIG en s'abonnant à la liste de diffusion PHP-FIG..

Cette liste de diffusion est l'endroit où les discussions, les votes, les suggestions et les commentaires ont lieu.

Le but

Le but de la FIG est de créer un dialogue entre les représentants du projet, dans le but de trouver des moyens de travailler ensemble (interopérabilité). Au moment de la rédaction de ce document, ce dialogue a engendré quatre recommandations concernant les normes PHP: PSR-0 à PSR-3..

Ces recommandations sont gratuites et peuvent être adoptées par n'importe qui, même si personne n'est obligé de le faire. En fait, les membres votants ne sont pas tenus de mettre en œuvre les RPSP dans les projets qu’ils représentent.!


PSR-0: Autoloader Standard

PSR-0 est un énorme pas en avant pour le code réutilisable.

Rappelez-vous comment vous aviez l'habitude de spécifier beaucoup exiger des instructions pour référencer toutes les classes dont vous avez besoin? Heureusement, ce modèle a changé avec la magie de PHP 5 __autoload () une fonction. PHP 5.1.2 a rendu le chargement automatique encore meilleur en introduisant spl_autoload (), qui vous permet d’enregistrer une chaîne de fonctions de chargement automatique avec spl_autoload_register ().

Quelle que soit la qualité de la fonctionnalité de chargement automatique, elle ne définit pas comment l'implémenter avec des bases de code existantes. Par exemple, bibliothèque X pourrait approcher la structure de répertoire et classname différemment de bibliothèque Y, mais vous voudrez peut-être utiliser les deux!

Écrire un autochargeur approprié, sachant où chercher tous les noms entièrement qualifiés possibles, et tester toutes les extensions de fichier (.class.php, inc.php, .php, etc.) va vite devenir un gâchis. Sans norme permettant de définir comment nommer les classes et où les placer, l'interopérabilité de l'autoloader resterait un rêve..

Rencontrez PSR-0. Une recommandation standard décrivant "les exigences obligatoires à respecter pour l'interopérabilité du chargeur automatique".

PSR-0 est un énorme pas en avant pour le code réutilisable. Si un projet est conforme à la norme PSR-0 et que ses composants sont faiblement couplés, vous pouvez simplement les prendre, les placer dans un répertoire "fournisseur" et utiliser un autochargeur compatible PSR-0 pour les inclure. Ou encore mieux, laissez Composer le faire pour vous!

Par exemple, c'est exactement ce que Laravel fait avec deux composants Symfony (Console et HttpFoundation).

La figure présente un exemple de mise en oeuvre d’une fonction d’autochargeur compatible PSR-0 pouvant être enregistrée dans spl_autoload_register (), mais vous êtes libre d'utiliser les implémentations les plus flexibles, telles que Symfony ClassLoader découplé ou l'autoloader de Composer..


PSR-1: norme de codage de base

Le PSR-1 se concentre sur une norme de codage de base.

Il y a eu une longue période de faible activité sur la figure après l'acceptation du PSR-0. En fait, il a fallu un bon an et demi avant que les documents PSR-1 et PSR-2 soient approuvés.

Le PSR-1 est basé sur une norme de codage de base. Il s'abstient d'être trop détaillé et se limite à un ensemble de règles de base pour "assurer un niveau élevé d'interopérabilité technique entre du code PHP partagé"..

  • Utilisez uniquement le et Mots clés.
  • Utilisez uniquement UTF-8 sans nomenclature pour le code PHP.
  • Effets secondaires distincts (générer une sortie, accéder à une base de données, etc.) et déclarations.
  • Appliquer le PSR-0.
  • Les noms de classe doivent être définis dans StudlyCaps.
  • Les constantes de classe doivent être définies en majuscules avec des séparateurs de soulignement.
  • Les noms de méthodes doivent être définis dans camelCase.

Les règles de base se concentrent sur les conventions de dénomination et la structure de fichier. Cela garantit que tout le code PHP partagé se comporte et se présente de la même manière à un niveau élevé. Imaginez une application qui utilise de nombreux composants tiers et qui utilisent tous des conventions de dénomination et des codages de caractères différents. Ce serait un gâchis!


PSR-2: Guide de style de codage

L'objectif du PSR-2 est de disposer d'un seul guide de style pour le code PHP, permettant d'obtenir un code partagé formaté de manière uniforme..

Le PSR-2 étend et étend les normes de codage de base du PSR-1. Son but est d'avoir un seul guide de style pour le code PHP qui donne un code partagé uniformément formaté..

Les règles du guide de style de codage ont été décidées après une enquête approfondie auprès des membres votants de la FIG..

Les règles de PSR-2, convenues par les membres votants, ne reflètent pas nécessairement les préférences de chaque développeur PHP. Depuis le début de la FIG, cependant, PHP-FIG a déclaré que ses recommandations avaient toujours été pour la FIG elle-même; d'autres qui sont disposés à adopter les recommandations sont un résultat positif.

La spécification complète du PSR-2 est disponible dans le référentiel fig-standards. Assurez-vous de le lire.

Dans un monde idéal, chaque projet PHP adopterait les recommandations contenues dans PSR-1 et PSR-2. Cependant, en raison de goûts ("convention de dénomination x plus belle que y!", "Onglets sur les espaces!") Et de la segmentation historique entre différents styles de codage, peu de projets PHP ont adopté PSR-1 et PSR 2 dans son intégralité.


PSR-3: interface de consignation

PSR-3 décrit une interface de journalisation partagée.

La recommandation 3 de la norme PHP est l’ajout le plus récent aux normes FIG acceptées. Il a été accepté le 27 décembre 2012 avec un nombre de votes impressionnant de 18 voix sur 0 (8 membres avec droit de vote n'ont pas voté).

Le PSR-3 décrit une interface de journalisation partagée, intégrant les huit niveaux Syslog du protocole Syslog (RFC 5424): débogage, informations, avis, avertissement, erreur, critique, alerte et urgence.

Ces huit niveaux Syslog sont définis en tant que noms de méthodes, qui acceptent deux paramètres: une chaîne avec un journal $ message et une option $ contexte tableau avec des données supplémentaires qui ne rentre pas bien dans la chaîne précédente. Les implémenteurs peuvent alors remplacer les espaces réservés dans $ message avec des valeurs de $ contexte.

Une norme d'interface partagée, telle que PSR-3, permet aux frameworks, bibliothèques et autres applications de saisir un indice sur cette interface partagée, permettant ainsi aux développeurs de choisir une implémentation préférée..

En d'autres termes: si un composant de consignation est réputé adhérer au PSR-3, il peut simplement être échangé avec un autre composant de consignation compatible PSR-3. Cela garantit une interopérabilité maximale entre les appels aux implémentations de consignateur.

Monolog a récemment mis en œuvre le PSR-3. Il est donc connu de mettre en œuvre le Psr \ Log \ LoggerInterface et ses directives associées trouvées dans le document PSR-3.


Critique

PHP-FIG fait un excellent travail de centralisation des normes PHP.

Certaines personnes disent que les RPS vont trop loin pour définir un ensemble global de normes définissant un style de codage - quelque chose de plus subjectif qu'objectif. D'autres pensent qu'une interface partagée est trop spécifique et non flexible. Mais la critique vient naturellement avec toute initiative standard. Les gens n'aiment pas la manière dont les identificateurs sont supposés être nommés, quelle indentation est utilisée ou comment les normes sont formées.

La plupart des critiques et des réflexions se déroulent de la ligne de touche, après les normes sont acceptées - même si les normes figurent dans la liste de diffusion (qui est ouverte à tout le monde et permet de laisser des commentaires, des commentaires ou des suggestions). N'hésitez pas à ouvrir un nouveau sujet dans la liste de diffusion si vous pensez avoir quelque chose de précieux à ajouter..

Il est également important de garder à l'esprit que ce n'est pas la combinaison spécifique de règles, qui contribue au bénéfice des normes recommandées, mais plutôt d'avoir un ensemble cohérent de règles partagées entre différentes bases de code..

Tout le monde évitant ses propres préférences, nous avons un style cohérent de l'extérieur, ce qui signifie que je peux utiliser TOUT package - pas seulement celui qui se trouve être camelCase..

- Phil Sturgeon dans la liste de diffusion PHP-FIG


L'avenir

La FIG a l'intention d'héberger un échantillon de l'écosystème PHP, pas seulement les développeurs de framework.

Avec un nombre croissant de membres votants influents et quatre normes acceptées, la FIG gagne certainement plus de poids dans la communauté PHP. Le PSR-0 a déjà une utilisation répandue, et nous espérons que PSR-1 et PSR-2 feront de même pour obtenir plus d'uniformité dans le code PHP partagé..

Avec l’interface partagée définie dans le PSR-3, le groupe d’interopérabilité du cadre prend un nouveau tournant en recommandant des normes. Ils se dirigent toujours dans cette direction, car le contenu des nouvelles interfaces partagées est en cours de discussion sur la liste de diffusion..

Il y a actuellement une discussion intéressante sur la proposition d'un paquet de messages HTTP, qui contient des interfaces partagées pour l'implémentation d'un client HTTP. Il existe également diverses discussions proposant une interface de cache partagée. mais, à partir de maintenant, il semble être sur la faible activité.

Quel que soit le résultat de ces propositions, PHP-FIG fait un excellent travail de centralisation des normes PHP. Ils influencent sans aucun doute l’écosphère PHP de manière positive, et espérons que leurs efforts gagneront une place plus importante dans le langage de programmation PHP..

.