Écrire du code selon les règles : Code Style et conventions PHP pour l'équipe

Travail en équipe : code style et conventions pour PHP

Imaginez que vous entrez dans un projet PHP qui n'est pas le vôtre. Vous ouvrez un fichier, et là — les tabulations sont mélangées avec des espaces, les variables sont nommées n'importe comment, et les accolades sont placées n'importe où, mais pas là où vous avez l'habitude. Ça vous dit quelque chose ? Maintenant, imaginez qu'il y a des centaines de fichiers comme celui-ci, et que chacun a été écrit par un développeur différent. Un cauchemar pour la code review et la maintenance du code.

Dans cet article, nous allons voir pourquoi le code style PHP et les conventions de code ne sont pas simplement un caprice du développeur senior, mais le fondement d'un travail d'équipe efficace. Vous découvrirez les standards PSR, les règles de nommage, de formatage et obtiendrez des exemples concrets que vous pouvez appliquer immédiatement dans votre projet.

Pourquoi le code style est-il important pour l'équipe ?

Lorsque plusieurs développeurs travaillent sur un projet, un style de code unifié devient un véritable soulagement. Voici pourquoi :

\n
• Lisibilité. Un code écrit selon des règles uniformes est facilement lu par n'importe quel membre de l'équipe. Inutile de deviner ce que l'auteur voulait dire.
\n
• Vitesse de la code review. Si le code est formaté de la même manière, le relecteur se concentre sur la logique, et non sur le formatage.
\n
• Moins de bugs. Des conventions uniformes réduisent la probabilité d'erreurs liées à des approches différentes de l'écriture du code.
\n
• Intégration facile. Un nouveau développeur s'intègre plus rapidement dans le projet si le code est prévisible et structuré.
\n

En substance, les standards de codage PHP sont la langue que parle toute l'équipe. Plus elle est uniforme, moins il y a d'incompréhensions.

Les standards principaux : PSR et autres

Dans le monde PHP, il existe plusieurs recommandations clés qui sont devenues des standards de facto. Les plus importantes sont le PSR-1 et le PSR-12 (anciennement PSR-2). Ils sont soutenus par le PHP-FIG (Framework Interoperability Group).

PSR-1 : Règles de base

Le PSR-1 décrit les règles les plus générales : comment nommer les classes, les méthodes, les constantes et comment organiser les fichiers.

Points principaux :

\n
• Les fichiers doivent utiliser uniquement <?php ou <?= (balise courte pour l'affichage).
\n
• L'encodage du fichier est UTF-8 sans BOM.
\n
• Les noms de classes en StudlyCaps (PascalCase).
\n
• Les noms de méthodes en camelCase.
\n
• Les constantes en majuscules avec des underscores (MAX_VALUE).
\n

Exemple de code correct selon PSR-1 :

<?php\n\nnamespace App\\Services;\n\nclass UserService\n{\n    const DEFAULT_ROLE = 'user';\n\n    public function getUserById(int $id): ?User\n    {\n        // logique\n    }\n\n    public function isAdmin(): bool\n    {\n        // logique\n    }\n}

PSR-12 : Règles de style avancées

Le PSR-12 est une évolution du PSR-2. Il ajoute plus de détails sur le formatage.

Points clés :

\n
• Indentation — 4 espaces (pas de tabulation).
\n
• Les accolades ouvrantes sont sur la même ligne pour les classes, les méthodes et les structures de contrôle (style K&R).
\n
• Un espace est obligatoire après les mots-clés (if, else, while).
\n
• Une ligne vide après la déclaration du namespace et avant le return dans les méthodes (optionnel).
\n
• Une ligne ne doit pas dépasser 120 caractères (80 recommandés).
\n

Exemple de formatage correct selon PSR-12 :

<?php\n\nnamespace App\\Controllers;\n\nuse App\\Models\\User;\nuse App\\Services\\AuthService;\n\nclass AuthController\n{\n    private AuthService $authService;\n\n    public function __construct(AuthService $authService)\n    {\n        $this->authService = $authService;\n    }\n\n    public function login(array $credentials): bool\n    {\n        if (empty($credentials['email']) || empty($credentials['password'])) {\n            return false;\n