« Le code propre » en PHP n’est pas une fantaisie esthétique : c’est un choix technique qui impacte la maintenance, les bugs, les délais de développement et la collaboration. En pratique, c’est ce qui vous permet de revenir sur un projet après des mois (ou de le transmettre à un autre développeur) sans avoir à le « déchiffrer » comme un message dans une bouteille.
Dans ce guide, nous mettons de l’ordre dans les règles fondamentales pour écrire du code propre en PHP : normes de formatage et conventions, types et mode strict, gestion des erreurs, organisation du projet, tests et principes SOLID appliqués. L’objectif est un : écrire un code plus lisible, plus prévisible et plus facile à modifier.
1) Commencez par une norme : PSR-12 et la cohérence avant le style
La première étape vers un code propre est simple : choisissez une norme et respectez-la toujours. En PHP, la norme la plus courante pour le style de code est PSR-12 (PHP-FIG), qui définit des lignes directrices sur l’indentation, l’espacement, les déclarations, l’organisation du code et bien plus encore. :contentReference[oaicite:0]{index=0}
La norme ne sert pas à « gagner des discussions » dans l’équipe : elle sert à réduire les frictions, à uniformiser le code et à permettre aux outils automatiques de faire le sale boulot (formatage et contrôles).
Règles pratiques (qui font vraiment la différence)
- Indentation cohérente (généralement 4 espaces, pas de tabulation).
- Espacement lisible autour des opérateurs et entre les blocs logiques.
- Une ligne vide entre les méthodes pour séparer les sections.
- Visibilité toujours déclarée (public/private/protected) pour les propriétés et les méthodes.
Ces lignes directrices sont souvent également résumées dans les bonnes pratiques de formatage pour les classes et les méthodes, comme dans l’exemple de référence qui cite PSR-12 comme norme officielle. :contentReference[oaicite:1]{index=1}
2) Nommage : si un nom est vague, le code est déjà plus difficile
Le code propre commence par les noms. Un nom incorrect « masque » la signification et oblige le lecteur à reconstruire mentalement l’intention. En PHP, une convention très utilisée est :
- Classes en PascalCase (ex.
OrderService) - Méthodes et variables en camelCase (ex.
calculateTotal())
C’est une règle simple, mais surtout, la cohérence est essentielle. Ici aussi, les lignes directrices de base (classes PascalCase, méthodes camelCase) sont un point fixe du formatage ordonné. :contentReference[oaicite:2]{index=2}
Liste de contrôle de nommage (rapide et utile)
- Préférez des noms spécifiques (pas
$data, mais$orderData). - Les méthodes devraient commencer par un verbe (
create,build,validate). - Évitez les abréviations cryptiques : elles économisent 2 caractères et coûtent 20 minutes.
3) Types et mode strict : moins d’ambiguïté, moins de bugs
PHP permet aujourd’hui un typage beaucoup plus robuste qu’auparavant. Si vous voulez un code propre, utilisez :
- des type hints pour les paramètres et le retour
strict_typesquand cela a du sens- des property types et la promotion de constructeur
<?php
declare(strict_types=1);
final class PriceCalculator
{
public function calculateTotal(float $net, float $vatRate): float
{
return $net * (1 + $vatRate);
}
}
Cette approche rend l’API de la classe plus claire, réduit les conversions implicites et aide les outils d’analyse statique.
4) Petites fonctions, responsabilités uniques : le principe qui paie toujours
Un indicateur immédiat de « code sale » est une fonction qui fait trop de choses : elle valide, transforme, enregistre sur la base de données, envoie des e-mails et peut-être écrit des logs. Quand tout est dans la même méthode, chaque modification devient risquée.
C’est là qu’intervient le premier principe SOLID, le Single Responsibility Principle (SRP) : une classe ne devrait avoir qu’une seule raison de changer. :contentReference[oaicite:3]{index=3}
Exemple (avant : tout ensemble, difficile à maintenir)
final class OrderController
{
public function checkout(array $payload): void
{
// valide l'entrée
// calcule les totaux
// enregistre la commande
// envoie un e-mail
// logge l'opération
}
}
Après : responsabilités séparées (plus propre, testable)
final class CheckoutService
{
public function __construct(
private OrderValidator $validator,
private OrderRepository $repository,
private Mailer $mailer,
private LoggerInterface $logger
) {}
public function checkout(OrderRequest $request): void
{
$this->validator->validate($request);
$order = Order::fromRequest($request);
$this->repository->save($order);
$this->mailer->sendOrderConfirmation($order);
$this->logger->info('Order created', ['id' => $order->id()]);
}
}
Ce n’est pas « plus long » : c’est plus clair. Et surtout, c’est plus facile à tester.
5) SOLID en PHP : ce qui change vraiment dans la pratique
Les principes SOLID sont cinq lignes directrices de conception orientée objet (OOP) conçues pour rendre le code plus maintenable, extensible et robuste. :contentReference[oaicite:4]{index=4}
S – Single Responsibility (une seule responsabilité)
Une classe ne devrait pas devenir un « conteneur de tout ». Si elle grossit trop, découpez-la en composants plus petits et plus ciblés.
O – Open/Closed (ouverte aux extensions, fermée aux modifications)
Lorsque vous ajoutez une fonctionnalité, essayez de l’étendre sans modifier le comportement existant (réduit les régressions). Exemple typique : stratégies, handlers, fournisseurs.
L – Liskov Substitution (substituabilité)
Si une sous-classe rompt les attentes de la classe de base, la hiérarchie est incorrecte. Si vous avez envie de « lancer des exceptions » parce qu’une méthode n’a pas de sens dans la sous-classe, vous signalez un problème de conception.
I – Interface Segregation (petites interfaces)
Mieux vaut plusieurs petites interfaces qu’une énorme qui oblige les classes à implémenter des méthodes inutiles.
D – Dependency Inversion (dépendre des abstractions)
Les classes de haut niveau devraient dépendre d’interfaces, pas de classes concrètes. Cela réduit le couplage et améliore la testabilité.
Si vous voulez un résumé clair des cinq principes et de leurs définitions, une source synthétique (avec une liste complète et la signification de chaque lettre) est également utile. :contentReference[oaicite:5]{index=5}
6) Évitez les « nombres magiques » et les constantes dispersées
Un autre classique du code difficile : des nombres et des chaînes répétés partout. Si une valeur est significative, donnez-lui un nom.
final class Invoice
{
private const VAT_STANDARD = 0.22;
public function vatRate(): float
{
return self::VAT_STANDARD;
}
}
C’est une bonne pratique simple et très souvent citée dans les règles de formatage et d’organisation du code. :contentReference[oaicite:6]{index=6}
7) Gestion des erreurs : exceptions, messages clairs, pas de silences
Un code propre signifie aussi des erreurs propres. Lignes directrices pratiques :
- Utilisez les exceptions pour les erreurs « exceptionnelles », pas pour le flux normal.
- Ne supprimez pas les erreurs avec
@. - Écrivez des messages qui aident vraiment à comprendre le problème.
throw new DomainException('Order total cannot be negative.');
Si une erreur ne laisse pas de trace, elle devient un bug « fantôme » : coûteux.
8) Commentaires : moins, mais meilleurs
Les commentaires ne doivent pas expliquer « ce que fait le code » si le code est déjà clair. Ils doivent expliquer :
- pourquoi un choix a été fait
- une contrainte métier
- un cas limite non évident
Même dans les lignes directrices de formatage, l’accent est mis sur des commentaires clairs et concis pour les logiques complexes. :contentReference[oaicite:7]{index=7}
9) Automatisez le style : formateurs et linters
La discipline manuelle ne s’adapte pas. Dans un projet réel, il est préférable d’automatiser :
- PHP-CS-Fixer ou PHP_CodeSniffer (avec les règles PSR-12)
- PHPStan ou Psalm pour l’analyse statique
- des hooks de pré-validation ou CI pour bloquer le code non conforme
Résultat : moins de discussions en revue et plus de temps sur l’architecture et la qualité.
10) Tests : le vrai multiplicateur de la propreté
Si le code n’est pas testable, il n’est souvent pas propre. Non pas parce qu’il « manque des tests », mais parce qu’il est trop couplé, trop grand ou trop dépendant de l’environnement.
Lorsque vous appliquez des principes comme SRP et Dependency Inversion, les tests unitaires deviennent plus faciles. Et lorsque les tests sont faciles, le refactoring devient durable.
Conclusion
Écrire du code propre en PHP signifie adopter des standards (comme PSR-12), soigner le nommage et le formatage, réduire l’ambiguïté avec les types, gérer les erreurs de manière explicite et concevoir avec des responsabilités claires. Les principes SOLID ne sont pas de la théorie : ils sont une boussole pratique pour écrire un code plus simple à maintenir, à étendre et à tester dans le temps. Si vous voulez un objectif concret : rendez le code lisible, prévisible et ennuyeux (dans le meilleur sens du terme). C’est ainsi qu’il devient professionnel.
Pubblicato in PHP
Soyez le premier à commenter