<img height="1" width="1" style="display:none" src="https://www.facebook.com/tr?id=410661216031617&amp;ev=PageView&amp;noscript=1">

Vous avez lancé un projet Web ? Vous faites appel à des développeurs PHP ? Vous êtes vous assuré que le code de votre site Web ou application respecte les règles de l'art en termes de qualité de code ?

Vous êtes un responsable digital ou un chef de projet Web ? Vous faites appel à des développeurs web pour développer votre site internet ou votre application Web? Vous avez changé d'équipe de développement ? Vous avez alors certainement déjà vu un développeur s’arracher les cheveux en lisant du code. Ils sont souvent confrontés à du code difficilement compréhensible, voire illisible dans le pire des cas 

Imaginez-vous lire un texte criblé de fautes, avec des erreurs de syntaxe, de la ponctuation utilisée à mauvais escient … Vous comprenez maintenant ce que ressentent les développeurs qui touchent à du code qui ne respecte pas les règles de l’art du codage ! 

Des bonnes pratiques existent en matière de développement Web. Elles permettent d’éviter ces difficultés et notamment de faciliter la lecture du code et la collaboration entre les développeurs (ou autres personnes susceptibles d’avoir à mettre les mains dans le code). Les PSR (ou PHP Standard Recommandationsont un ensemble de standards, des normes, spécifiques à la programmation PHP.

L’objectif ? Fournir une base technique commune pour améliorer les pratiques de programmation en PHP et permettre l’interopérabilité des composants pour faire fonctionner les frameworks ensemble. 

Vous voulez savoir à quoi correspondent ces PSR ? Nous allons y venir ! Mais commençons d’abord par vous présenter le FIG, le groupe de travail à l’origine des PSR.

Qu’est-ce que FIGle Framework Interop Group ?

php-fig-logoFIG : qui se cache derrière cet acronyme ? Il s’agit du groupe PHP Framework Interop Group. Il a été initié par 5 développeurs en 2009. Plusieurs autres développeurs à l’initiative de projets divers ont désormais rejoint le groupe. 

Voilà comment ils se décrivent : 

Nous sommes un groupe de projets PHP établis dont le but est de parler des points communs entre nos projets et de trouver des moyens de mieux travailler ensemble.

Ils n’ont pas la prétention de se présenter comme un exemple ou des référents en matière de programmation PHP. D’ailleurs, on parle bien de « recommandations » et rien ne vous oblige à les suivre.  

Ces recommandations sont toutefois appréciées de la communauté PHP et largement reconnues. 

Pour rappel, PHP est un langage de programmation ! Un petit doute ? Voilà un petit dico des mots et expressions des développeurs Web.


Les PSR plus en détails 

Je vous ai expliqué rapidement plus haut ce quétait une PSR.  

Petite piqûre de rappel : c’est un standard de programmation (ou bonne pratique) spécifique à PHP. L’idée est d’harmoniser les méthodes de développements. 

On peut les regrouper en 4 grandes catégories : 

  • Le chargement automatique : PSR-4 
  • Les interfaces : PSR-3, PSR-6, PSR-11 … 
  • HTTP ou la gestion des messages HTTP : PSR-7, PSR-15 … 
  • Et les styles de codage : PSR-1, PSR-12. 

Un bon exemple (ou quatre 😊 ) étant plus clair que milles explications, voici une présentation des quatre PSR les plus connues. 

 

Les PSR-1 et PSR-2 / PSR-12 : les bases  

Autant commencer cette présentation des PSR par les numéros 1 et 2 (ou 12 ! Vous comprendrez bientôt où je veux en venir). Je vous les présente ensemble parce qu’elles sont liées. 

Elles fixent les conventions minimales de codage, les éléments requis pour assurer un haut niveau d’interopérabilité entre les codes PHP partagés 

La PSR-1 présente les normes de codage de base : 

  • Les fichiers doivent utiliser uniquement les balises <?php et <?= . 
  • Le code doit utiliser les balises longues ou à écho court et ne doit pas utiliser les autres variantes de balises. 
  • Le code PHP doit utiliser uniquement UTF-8 (le codage de caractères universel/international pour éviter les défauts d’affichage des caractères). 
  • Les noms de méthode doivent être déclarés dans camelCase(). 
  •  

Bref, vous comprenez que l’idée générale est d’établir des normes de codage : quelle balise utiliser, comment déclarer tel ou tel élément... et ce afin de faciliter la lecture et la compréhension par tous.

 

Un exemple en image :

psr-1 - constantes

"Les constantes de classe DOIVENT être déclarées en majuscules avec des séparateurs de soulignement"

La PSR-2 intitulée “Guide de style de codage” est certainement l’une des plus connues. Elle a été déclarée comme obsolète en 2019 et remplacée par la PSR-12 “Guide de style de codage étendu”. 

En voici quelques extraits : 

  • La limite logicielle sur la longueur de ligne doit être de 120 caractères. 
  • Les lignes de devraient pas contenir plus de 80 caractères ou alors être divisées en plusieurs lignes de 80 caractères maximum chacune. 
  • Tous les mots-clés et types PHP réservés doit être en minuscules. 
  • Toute accolade de fermeture ne doit pas être suivie d’un commentaire ou d’une déclaration sur la même ligne. 
  • Et bien d’autres ! 

Bref, pour faire simple, c’est un peu comme si vous deviez écrire un texte et qu’on vous disait “Ne rédige pas des phrases de plus de 10 mots, écris les noms de familles en majuscules, sautes une ligne entre deux phrases…” 

 

Un exemple en image :

"l'accolade d'ouverture pour la classe DOIT aller sur sa propre ligne" psr-12 - accolades

 

La PSR-4, une amélioration de la PSR-0 

La PSR-4 décrit une spécification pour les classes de chargement automatique à partir de chemin de fichiers. Vous n’avez rien compris ? C’est normal, on rentre un peu dans la technique…   

Un projet Web est constitué de plusieurs fichiers rangés dans des dossiers. En PHP, on utilise ce qu’on appelle des “namespaces (ou espaces de noms)” pour représenter la structure, l’organisation des fichiers dans le code. 

Les namespaces sont des groupes, des conteneurs de noms. On s’en sert pour distinguer deux éléments qui ont le même nom. 

Voici un exemple : un fichier nommé "rose" peut se retrouver à la fois dans le namespace "couleurs" et dans le namespace "fleurs".

La PSR-4 donne des directives sur la façon d’écrire ces namespaces pour donner une présentation de la structure des fichiers la plus claire possible. Comment puis-je trier et ranger mes livres pour que tout le monde s’y retrouve dans ma bibliothèque ? 😉

 

Un exemple en image :

"Un nom de classe complet a la forme suivante:"psr-4 - nom de classe

 

 

La PSR-7, interfaces de messages HTTP 

Les messages HTTP sont la base du développement Web.  

Vous ne le voyez pas mais le navigateur web que vous utilisez crée des requêtes HTTP, qui sont envoyées à un serveur Web, qui fournit alors une réponse HTTP. 

Illustrons un peu la chose pour mieux comprendre le concept :  

Vous êtes sur la page web 1. Vous cliquez sur la pagination pour accéder à la page 2. Votre navigateur envoie un message HTTP (une requête) au serveur, de type “Donne-moi la page 2”.  Le serveur lui envoie un message HTTP en retour, une réponse “Voici la page que tu as demandée”. 

On ne va pas entrer ici dans des détails techniques mais sachez que la PSR-7 décrit la façon de présenter les messages HTTP dans le code. 

PSR, la fausse bonne idée ?

Toutes les recommandations du PHP FIG n'ont pas connu le même succès. Certaines ont fait couler beaucoup d'encre et pas toujours pour les bonnes raisons...  La PSR-7 a elle-même ouvert le débat.

Pour rappel, la PSR-7 appelée HTTP message interfaces définit une façon commune de concevoir les messages HTTP.  De nombreux projets sous Symfony, Drupal 8 ou encore Laravel utilisent les classes Request et Response proposées par Symfony via le composant HttpFoundation. Or, la PSR-7 et HttpFoundation diffèrent fondamentalement, notamment par ce que les messages PSR-7 sont immutables alors que la mutabilité est dans l'ADN de HttpFoundation... C'est peut-être un peu technique mais notez simplement que PSR-7 a définit une norme qui repose sur l'inverse ce qui est prévu par Symfony, du moins sur ce point là.

Difficile donc pour Symfony de s'aligner sur les règles définies par la PSR-7 puisqu'il repose entièrement sur ce composant HttpFoundation.

Vous comprendrez que Symfony s'est vu en quelque sorte "obligé" de créer une bibliothèque permettant de convertir les objets Request et Response en une version compatible avec PSR-7. On croyait pourtant que le PHP-FIG ne voulait rien imposer à personne, non ? 🤔

Il ne s'agit là que d'un exemple évidemment et chaque développeur a son avis sur la question.

Le cycle de validation des PSR ou comment une recommandation devient une PSR ? 
 

Le groupe de travail, assez représentatif de l’écosystème PHP, émet des recommandations (les fameuses PSR) qui suivent une série d’étapes avant d’être validées (ou pas validées d’ailleurs !) : 

  • Avant-projet ils déterminent si la majorité des intervenants PHP FIG est intéressée par l’idée proposée et discutent d’une proposition éventuelle, notamment des mises en œuvre possibles. psr-standards-programmation-php
  • Brouillon : ils étudientdiscutent, peaufinent le concept proposé afin qu’ils puissent être examiné par le comité central de la FIG. 
  • La revue : c’est la phase d’expérimentation ! Ils testent alors le concept. 
  • Accepté : la proposition devient officiellement une PSR 🎉 
  • Dépréciée : une PSR dépréciée est une PSR obsolète. Elle a été approuvée mais n’est plus considérée comme pertinente. Les PSR dépréciées sont dans les faits souvent remplacées par des PSR plus actuelles. C’est le cas, par exemple, de la PSR-2, remplacée par la PSR-12 (on y revient un peu plus loin...) 
  • Abandonnée : une PSR non utilisée et finalement abandonnée 😭 

 

Vous avez maintenant compris ce que sont les normes PSR, du moins je l’espère ! Je n’ai abordé que les plus connues mais vous pouvez toutes les retrouver sur le site du FIG .  

Le PHP-FIG s'est donné la mission compliquée de réunir les communautés existantes de l'écosystème PHP. Si le groupe a rencontré plusieurs succès, il y a aussi eu des échecs qui ont même poussé certains membres à quitter le mouvement ...
 
Ces recommandations font débat dans la communauté PHP. Doit-on les utiliser ou non ? Chacun y va de son avis et, comme je vous l’indique plus haut, chacun est libre de les appliquer ou non.  
 
La démarche est somme toute intéressante car elle a le mérite de tendre vers l’harmonisation des méthodes de développements !

Webinar - Comment réussir son projet d'application mobile ?

Publié par Nathalie Ferreira
Retrouvez moi sur :

Un conseil, un projet, un devis ?
Nous repondons a toutes vos questions !

N'hésitez pas à nous contacter pour plus d'informations

Nous contacter

Sur les mêmes sujets