Parlons PSR #2 : PSR-1 – Standard de code

Je vous ai parlé dans un article précédent de la PSR-FIG et pourquoi elle existe et dans quels cas appliquer ses conseils. Beaucoup de framework propose des versions alternatives avec des implémentations PSR (comme PSR-7 ou PSR-4) aujourd’hui sur Github.

Celui qui nous intéresse aujourd’hui c’est le PSR-1. Ce PSR pose les bases de la programmation en PHP et on va détailler les différents points avec des exemples car nous aussi, nous allons poser les bases de cette série.

Le PSR-1, accepté, édité par Paul M. Jones.

Bases d’écriture des programmes

Ce PSR-1 défini les bases pour développer en PHP. Je ne parlerai pas du PSR-0 qui est “deprecated” et est remplacé par le PSR-4.

Dans cette partie nous allons traduire et comprendre les différents conseils du PSR-1. C’est parti !

Le tag PHP

Les tags PHP permettent de définir qu’un fichier contient du php entre ces tags.

Selon la PSR-FIG les seuls tags à utiliser sont :

  • La version longue : <?php ?>
  • La version courte : <?= ?>

J’avoue que par défaut, j’utilise toujours la version longue. La version courte étant peu reconnaissable et peu usitée.

Encodage des caractères

Les fichiers PHP doivent être encodés en UTF-8 sans BOM. Mais ça veut dire quoi ?

On connait tous UTF-8 qui permet d’encoder nos caractères.

Le BOM, pour Byte Order Mark (ou Indicateur d’ordre des octets), permet de définir l’ordre ainsi que l’encodage du fichier et se trouve en début de fichier. Le problème avec l’utilisation des BOM est la compatibilité entre les éditeurs de fichiers et la lecture de ces mêmes fichiers. Dans le cas de PHP, cela peut interférer avec l’analyseur (lexicale) qu’il pourrait ne pas reconnaitre.

Effets secondaires

Un fichier doit déclarer des nouveaux symboles sans causer d’effets secondaires.

Il faut ici faire la différence entre déclaration et le reste. Inclure un fichier n’est pas une déclaration. Déclarer une fonction est une déclaration. Créer une classe est une déclaration, mais afficher un texte n’en est pas. En clair, une déclaration c’est définir un identifiant vers une adresse mémoire. L’exemple du PSR est très parlant et je vous le conseils.

Cela est une logique pour éviter que trop de code ne se croise. Cela permet aussi outre mesure de respecter les principes SOLID.

Ce n’est pas vraiment le cas, mais ça suit un peu cette logique de responsabilité appliqué à un fichier.

Espaces de noms et noms des classes

Les espaces de noms doivent suivre une convention d’autoloading (PSR-4, on oubli pour le moment le PSR-0) que nous verrons plus tard.

Chaque classe doit être dans un fichier qui porte son nom et doit être contenue dans au moins UN espace de nom correspondant au nom globale (du “vendor”).

Tout cela doit être en StudlyCaps. C’est a dire :

MaClasseSeNommeCommeCa.php

namespace MonApplication;
class MaClasseSeNommeCommeCa 
{
// du code
}

Pour les versions antérieures à PHP 5.3, on utilise le pseudo espace de nom car les namespace n’existaient pas :

MaClasseSeNommeCommeCa.php

class MonApplication_MaClasseSeNommeCommeCa 
{
// du code
}

Encore une fois, cela permet de maintenir une cohérence dans l’ensemble du code.

Constantes, propriétés et méthodes de classes

Je fais une liste rapide car ce PSR n’est pas très complexe à comprendre :

  • Les constantes doivent être déclarées en majuscules
  • Les méthodes doivent être déclarées en camelCase()
  • Les propriétés (variables) n’ont pas de convention précise. Mais si une convention est utilisée, il faut l’utiliser sur l’ensemble du code.

Encore une fois pour maintenir la cohérence entre les différents codes PHP.

Récapitulatif

MaClasse.php //Le nom de mon fichier = nom de ma classe

namespace MonAppli; //Namespace minimum avec mon nom de "vendor"
class MaClasse
{
  const VERSION = '1.0'; //Constante en majuscule
  private $premiere_var = 1;
  private $seconde_var = 2; //je suis mon "case" de déclaration

  public function maFunctionEnCamelCase($variable_autre)
  {
    // du code
  }
}

Voilà ! Vous savez tout sur le PSR-1 !

Laisser un commentaire