Clean Code en PHP : principes et exemples pratiques

Introduction : pourquoi le code propre en PHP n'est pas un luxe, mais une nécessité

Chaque développeur PHP a déjà été confronté à une situation où un simple bug en production se transforme en une chasse de plusieurs heures au « diable dans les détails ». Le plus souvent, la cause ne réside pas dans la complexité de la logique, mais dans un code sale : des noms de variables insensés, des fonctions de 500 lignes, l'absence de types et des commentaires mensongers. Clean Code (Code propre) n'est pas qu'une question d'esthétique. C'est un outil qui réduit le coût de maintenance d'un projet de 3 à 5 fois et permet aux nouveaux membres de l'équipe de s'intégrer au projet en quelques heures, et non en semaines.

Dans cet article, nous allons décortiquer les principes clés du Clean Code appliqués à PHP, en les illustrant par des exemples concrets avant et après refactoring. Vous apprendrez à appliquer les normes PSR, les principes SOLID et les règles simples de nommage pour que votre code parle de lui-même.

1. Nommage des variables, fonctions et classes : parlez le langage du métier

Un mauvais nom est le principal ennemi de la lisibilité. Si une variable s'appelle $a ou $data, chaque fois que vous lisez le code, vous gaspillez des ressources mentales à le décoder. La règle est simple : le nom doit répondre à la question « Qu'est-ce que c'est ? » ou « Qu'est-ce que ça fait ? »

Mauvais exemple

<?php// Qu'est-ce que $d ? Pourquoi $x = 2 ?$d = new DateTime();$x = 2;$y = $d->modify('+' . $x . ' days');echo $y->format('Y-m-d');?>

Bon exemple (Clean Code)

<?php$currentDate = new DateTime();$daysToAdd = 2;$futureDate = $currentDate->modify('+' . $daysToAdd . ' days');echo $futureDate->format('Y-m-d');?>

Règles supplémentaires :

• Classes et interfaces — des noms : UserRepository, PaymentGatewayInterface.
• Méthodes — des verbes : getUserById(), sendEmailNotification().
• Variables booléennes — préfixes is, has, can : $isActive, $hasPermission.
• Évitez les abréviations : $cnt → $count, $usr → $user.

2. Fonctions et méthodes : le principe de responsabilité unique (SRP) en action

Une fonction = une action. Si vous voyez une fonction de plus de 20 à 30 lignes, il y a de fortes chances qu'elle puisse être divisée. En PHP, c'est particulièrement pertinent car l'absence de typage strict (avant PHP 7.4) encourage les « fourre-tout » de code.

Mauvais exemple : la fonction couteau suisse

<?phpfunction processOrder(array $orderData): array{    // Validation    if (empty($orderData['email'])) {        throw new InvalidArgumentException('Email required');    }    // Sauvegarde en BDD    $pdo = new PDO('mysql:host=localhost;dbname=test', 'root', '');    $stmt = $pdo->prepare('INSERT INTO orders (email, total) VALUES (?, ?)');    $stmt->execute([$orderData['email'], $orderData['total']]);    // Envoi d'email    mail($orderData['email'], 'Order Confirmed', 'Thank you!');    // Journalisation    file_put_contents('log.txt', 'Order processed: ' . $orderData['email'] . PHP_EOL, FILE_APPEND);    return ['status' => 'success'];}?>

Bon exemple : séparation des responsabilités

<?phpclass OrderProcessor{    private OrderValidator $validator;    private OrderRepository $repository;    private MailService $mailer;    private Logger $logger;

    public function __construct(        OrderValidator $validator,        OrderRepository $repository,        MailService $mailer,        Logger $logger    ) {        $this->validator = $validator;        $this->repository = $repository;        $this->mailer = $mailer;        $this->logger = $logger;    }

    public function process(array $orderData): arr