Code Review PHP : 8 points essentiels à vérifier pour chaque développeur

Pourquoi le code review ne se limite pas à "trouver des bugs"

Imaginez : vous avez écrit un code parfait. Il fonctionne, passe les tests, et même le client est satisfait. Mais lors du code review, un collègue arrive et... ça commence. "Pourquoi utiliser == au lieu de === ?", "Cette méthode fait 5 choses à la fois", "Où est la gestion des exceptions ?". Ça vous parle ?

En réalité, le code review en PHP ne se résume pas à la chasse aux bugs (même si c'en est une partie). C'est un moyen de rendre le code lisible, sécurisé et maintenable. Surtout en PHP, où 25 ans d'évolution ont accumulé de nombreux pièges.

Dans cet article, nous allons voir ce qu'il faut vérifier lors d'un code review PHP pour que le code non seulement fonctionne, mais soit un modèle de qualité. Prêt ? C'est parti !

1. Typage et modes stricts

PHP 7+ et 8 nous ont offert des outils puissants pour le contrôle des types. Pourtant, de nombreux projets vivent encore en "mode chaos".

Ce qu'il faut vérifier :

\n
• Les types des arguments et des valeurs de retour sont-ils déclarés ? Si une méthode attend int et qu'on lui passe string, c'est un sujet de discussion.
\n
• Y a-t-il declare(strict_types=1); en début de fichier ? Sans cela, PHP effectuera des conversions implicites de types, ce qui entraîne souvent des erreurs cachées.
\n

<?php\ndeclare(strict_types=1);\n\n// Mauvais : pas de types\nfunction calculate($a, $b) {\n    return $a + $b;\n}\n\n// Bon : typage strict\nfunction calculate(int $a, int $b): int {\n    return $a + $b;\n}\n?>\n

Conseil pour le code review : si vous voyez mixed ou array sans spécification, posez la question "Qu'est-ce qui est attendu ici exactement ?".

2. Sécurité : injections SQL et XSS

PHP est comme un couteau suisse : beaucoup de fonctions, et beaucoup sont dangereuses. Surtout dans le code legacy.

Top 3 des drapeaux rouges :

\n
• Concaténation dans les requêtes SQL. Si vous voyez "SELECT * FROM users WHERE id = ".$_GET['id'], c'est un appel à l'aide.
\n
• Affichage de données sans échappement. echo $userInput; — bonjour les failles XSS.
\n
• Stockage des mots de passe en texte clair. Sérieusement, ça existe encore.
\n

<?php\n// Dangereux !\n$sql = "SELECT * FROM users WHERE email = '" . $email . "'";\n\n// Sécurisé (PDO)\n$stmt = $pdo->prepare("SELECT * FROM users WHERE email = :email");\n$stmt->execute(['email' => $email]);\n?>\n

Lors d'un code review PHP, vérifiez toujours la gestion des données externes. Tout $_GET, $_POST, $_COOKIE doit passer par une étape de filtrage.

3. Respect des normes PSR

La communauté PHP a créé les PSR (PHP Standards Recommendations) pour une bonne raison. C'est le langage commun de tous les développeurs PHP.

Ce qui doit figurer dans chaque PR :

\n
• PSR-12 (style de codage) : indentation de 4 espaces, accolades sur une nouvelle ligne pour les classes, espaces autour des opérateurs.
\n
• PSR-4 (autoloading) : les namespaces doivent correspondre au chemin du fichier.
\n
• Noms de classes en StudlyCaps, méthodes en camelCase, constantes en UPPER_CASE.
\n

<?php\nnamespace App\\Service;\n\nclass UserService  // PSR-4 : le fichier doit être dans src/Service/UserService.php\n{\n    public function getUserById(int $id): ?User  // camelCase\n    {\n        // ...\n    }\n}\n?>\n

Astuce : si le projet n'a pas de formatage automatique (PHP CS Fixer, PHP_CodeSniffer), c'est le premier point à améliorer.

4. Complexité et architecture

Un bon code se lit comme un livre. Un mauvais code, comme le déchiffrement d'un manuscrit ancien.

Points d'attention :

\n
• Longueur des méthodes. Si une méthode dépasse 20-30 lignes, c'est probablement le signe qu'elle en fait trop.
\n