Actuellement en poste chez France Télévisions j’ai fait adopté à mes équipes et mes sous traitants la suite de convention PSR. Pour ceux qui auraient loupé un épisode dans le fabuleux monde de PHP mais surtout sur dans un monde qui veut aller vers du mieux, PSR c’est une suite de “normes”. Actuellement il y a 4 chapitres dans PSR nommés très justement PSR-0, PSR-1, PSR-2 et je vous le donne dans le mille, PSR-3.

C’est une suite qui va plus loin qu’une “simple” convention PEAR ou ZEND, je ne vais pas tout vous citer ici mais voici ce que vous trouverez dans chaque chapitre.

PSR-0

L’objectif c’est en se basant sur le namespace d’une classe être capable de la charger. C’est ce qu’on appelle l’autoloader.

Toutes les infos sur github : https://github.com/php-fig/fig-standards/blob/master/accepted/PSR-0.md

PSR-1

L’objectif c’est de définir une convention de codage “à minima”

• Files MUST use only <?php and <?= tags.
• Files MUST use only UTF-8 without BOM for PHP code.
• Files SHOULD either declare symbols (classes, functions, constants, etc.) or cause side-effects (e.g. generate output, change .ini settings, etc.) but SHOULD NOT do both.
• Namespaces and classes MUST follow PSR-0.
• Class names MUST be declared in StudlyCaps.
• Class constants MUST be declared in all upper case with underscore separators.
• Method names MUST be declared in camelCase.

Toutes les infos sur github : https://github.com/php-fig/fig-standards/blob/master/accepted/PSR-1-basic-coding-standard.md

PSR-2

L’objectif est d’enrichir PSR-1. Il n’y a qu’un point avec lequel je suis en désaccord, c’est la limitation du nombre de caractères par ligne que je trouve trop bas.

• Code MUST follow PSR-1.
• Code MUST use 4 spaces for indenting, not tabs.
• There MUST NOT be a hard limit on line length; the soft limit MUST be 120 characters; lines SHOULD be 80 characters or less.
• There MUST be one blank line after the namespace declaration, and there MUST be one blank line after the block of usedeclarations.
• Opening braces for classes MUST go on the next line, and closing braces MUST go on the next line after the body.
• Opening braces for methods MUST go on the next line, and closing braces MUST go on the next line after the body.
• Visibility MUST be declared on all properties and methods; abstract and final MUST be declared before the visibility;static MUST be declared after the visibility.
• Control structure keywords MUST have one space after them; method and function calls MUST NOT.
• Opening braces for control structures MUST go on the same line, and closing braces MUST go on the next line after the body.
• Opening parentheses for control structures MUST NOT have a space after them, and closing parentheses for control structures MUST NOT have a space before.

Toutes les infos sur github : https://github.com/php-fig/fig-standards/blob/master/accepted/PSR-2-coding-style-guide.md

PSR-3

L’objectif c’est de définir comment votre application doit logger des évènements. Je trouve l’idée intéressante mais je suis un peu dubitatif sur le fait que ce soit un standard.

Toutes les infos sur github : https://github.com/php-fig/fig-standards/blob/master/accepted/PSR-3-logger-interface.md

 

Je continue sur PSR, pour ceux qui voudraient passer leur code aux normes PSR, Sensio Labs (Symfony) a publié un outil pour faciliter la mise en place : http://cs.sensiolabs.org/. Je ne l’ai pas testé personnellement, mais je suis preneur de vos retours dans les commentaires 😉

Enfin pour terminer le chapitre PSR, voici un outil pour vérifier dans votre environnement d’intégration continue que tout est conforme, grâce à une implémentation des rulesets de PHP_CodeSniffer disponible ici :https://github.com/klaussilveira/phpcs-psr .

Voila ça fait une petite piqûre de rappel ou qui sera peut être une grande découverte pour d’autres 😉