Mauvais code en programmation : ce que c’est, les signes et comment écrire plus proprement

Qu’est-ce que le mauvais code en programmation

Le mauvais code est une caractérisation subjective mais généralement acceptée d’un code qui ne répond pas aux normes minimales de qualité. Robert Martin dans son livre Clean Code (2008) définit le mauvais code comme un code qui « empêche de comprendre ce qu’il fait ». Le mauvais code peut être syntaxiquement correct et même fonctionner, mais sa maintenance devient un cauchemar pour l’équipe.

Le terme mauvais code est particulièrement répandu dans la communauté russophone. En anglais, des termes plus formels sont utilisés : spaghetti code, dirty code, technical debt code. Cependant, la coloration émotionnelle de « mauvais code » transmet plus précisément l’attitude des développeurs envers ce type de code — un mélange d’irritation, de dégoût et d’offense professionnelle.

Selon une étude de McKinsey (2023), les entreprises ayant un niveau élevé de dette technique — et le mauvais code en est le principal composant — dépensent 20–40% de ressources supplémentaires pour développer de nouvelles fonctionnalités. La qualité du code affecte directement les indicateurs métier, et ce n’est pas une métaphore mais un fait confirmé.

La frontière entre le mauvais code et le code normal

Il n’existe pas de métriques objectives, mais il y a des critères pratiques : si un développeur met plus de 5 minutes à comprendre une fonction de 20 lignes — c’est du mauvais code. Si la modification d’une ligne casse trois modules non liés — c’est du mauvais code. Si le code ne peut pas être couvert par des tests sans une réécriture complète — c’est du mauvais code.

Principaux signes du mauvais code

Le copier-coller (copy-paste programming) est l’un des signes les plus évidents et les plus faciles à détecter. Lorsque le même bloc de code se répète à plusieurs endroits avec des modifications minimes, ce n’est pas simplement du mauvais code — c’est une source de futurs bugs. Corriger à un endroit et oublier à un autre est une situation typique.

Les noms de variables insignifiants sont un classique. Des variables nommées `a`, `b`, `x`, `data`, `temp`, `tmp`, `result`, `list`, `obj` ne portent aucune information sur leur objectif. Le lecteur du code doit analyser toute la fonction pour comprendre ce que contient la variable. Robert Martin appelle cela « un mensonge dans le nom » — le nom promet des informations mais ne les livre pas.

L’imbrication profonde — lorsque les conditions, les boucles et la gestion d’erreurs créent une structure avec 5+ niveaux d’indentation. Un tel code est impossible à lire sans défilement horizontal ou suivi mental de tous les niveaux. C’est une voie directe vers les erreurs : les opérateurs logiques sont facilement confondus et les parenthèses fermantes sont oubliées.

Signes cachés

Code mort (dead code) — fonctions, variables, classes qui ne sont utilisées nulle part. Cela augmente le volume de code, distrait le développeur et crée une fausse impression des capacités du système. Nombres magiques — nombres sans contexte. Classes God — classes qui font tout à la fois, violant le principe de responsabilité unique (SOLID : S).

Pourquoi le mauvais code apparaît

Le manque de temps est la raison la plus courante. Lorsque les délais approchent, les développeurs sacrifient la qualité au profit de la vitesse. Tactiquement, cela peut être justifié, mais stratégiquement — c’est accumuler de la dette technique. Le problème est que le mauvais code « temporaire » est rarement revu pour être corrigé.

L’absence de revue de code est la deuxième raison la plus importante. Lorsque le code est écrit seul sans vérification par les pairs, les mauvais schémas s’enracinent et se multiplient. La revue de code n’est pas seulement un contrôle de qualité mais aussi un transfert de connaissances au sein de l’équipe. Les projets sans revue dégénèrent inévitablement en mauvais code.

La faible qualification du développeur ou l’absence de mentorat. Les développeurs juniors laissés sans supervision écrivent naturellement du mauvais code — cela fait partie du processus d’apprentissage. Le problème survient lorsque ce code arrive en production sans revue ni refactoring.

Facteurs culturels

Dans les équipes où « ça marche, c„st bon » est la devise, le mauvais code prospère. L’absence de normes de codage, d’exigences de test et de processus de revue crée un environnement où la qualité du code n’est la préoccupation de personne. Ces projets deviennent rapidement du « legacy » — un code que tout le monde craint de toucher.

Conséquences du mauvais code pour le projet

La principale conséquence du mauvais code est le ralentissement du développement. Le paradoxe du mauvais code est qu’il permet d’écrire rapidement la première version, mais chaque correction ultérieure prend de plus en plus de temps. Le graphique de la vitesse de développement par rapport à la qualité du code est exponentiel — après un certain seuil, l’ajout de nouvelles fonctionnalités devient pratiquement impossible.

Le turnover du personnel est une conséquence indirecte mais grave. Les développeurs, surtout les plus expérimentés, ne veulent pas travailler avec du mauvais code. Selon l’enquête Stack Overflow Developer Survey 2024, 47% des développeurs citent la qualité de la base de code comme l’un des facteurs clés lors du choix d’un lieu de travail. Les projets avec du mauvais code perdent leurs meilleurs employés.

La sécurité est une autre victime du mauvais code. Le code mal écrit contient plus de vulnérabilités : exceptions non gérées, injections SQL, XSS, fuites mémoire. Un code de qualité avec des tests unitaires et une revue de code détecte la plupart de ces problèmes avant la production.

La dette technique comme métrique

SonarQube et les outils similaires peuvent estimer la dette technique en heures-homme ou en jours. Par exemple, 500 avertissements de copier-coller, 200 de nombres magiques et 50 d’imbrication profonde donnent une estimation de 30 jours de dette technique. Ces chiffres peuvent et doivent être montrés à la direction pour justifier le refactoring.

Comment écrire du code propre au lieu de mauvais code

Le principe DRY (Don’t Repeat Yourself) est la première chose à implémenter. Chaque fragment de logique doit exister en un seul endroit. Au lieu du copier-coller — extrayez le code répétitif dans une fonction, une classe ou un module séparés. Au lieu des nombres magiques — des constantes nommées. Au lieu de longues fonctions — plusieurs petites.

Le principe KISS (Keep It Simple, Stupid) protège contre la complexité excessive. Si une tâche peut être résolue en 10 lignes — n’en écrivez pas 50. Si une boucle est plus simple qu’un stream — utilisez une boucle. Si une fonction ordinaire est plus claire qu’un décorateur — écrivez une fonction. La simplicité est la principale qualité d’un code maintenable.

La règle Boy Scout — « laissez le code meilleur que vous ne l’avez trouvé ». Même les petites améliorations à chaque modification transforment progressivement le mauvais code en code correct. Renommer une variable, diviser une grande fonction, ajouter un test — toute amélioration compte.

// mauvais code — copier-coller, nombres magiques, noms pauvres
function calc(a, b, c) {
  let x = a * 0.85;
  if (b > 1000) { x = x * 0.9; }
  let y = c * 0.85;
  if (b > 1000) { y = y * 0.9; }
  return x + y;
}

// code propre — noms clairs, DRY, constantes
const DISCOUNT_RATE = 0.85;
const BULK_THRESHOLD = 1000;
const BULK_DISCOUNT = 0.9;

function applyDiscount(amount, quantity) {
  let price = amount * DISCOUNT_RATE;
  if (quantity > BULK_THRESHOLD) {
    price = price * BULK_DISCOUNT;
  }
  return price;
}

function calculateTotal(items, quantity) {
  return items.reduce((sum, item) => {
    return sum + applyDiscount(item, quantity);
  }, 0);
}

Exemples de refactoring

Considérons un exemple typique en Python. La fonction traite les commandes mais le fait mal : 80 lignes, imbrication profonde, nombres magiques, duplication. Après le refactoring, le code devient lisible, testable et maintenable.

# mauvais code — une seule fonction fait tout
def process_order(order):
    if order.get("type") == "premium":
        if order["amount"] > 100:
            discount = 0.8
        else:
            discount = 0.9
    else:
        discount = 1.0
    total = order["amount"] * discount
    return total

# code propre — fonctions et constantes extraites
class OrderProcessor:
    PREMIUM_DISCOUNT_HIGH = 0.8
    PREMIUM_DISCOUNT_LOW = 0.9
    PREMIUM_THRESHOLD = 100

    def get_discount(self, order):
        if order.type == "premium" and order.amount > self.PREMIUM_THRESHOLD:
            return self.PREMIUM_DISCOUNT_HIGH
        return self.PREMIUM_DISCOUNT_LOW

    def calculate_total(self, order):
        return order.amount * self.get_discount(order)

La règle des trois lignes pour les fonctions

Une bonne fonction fait une chose et le fait bien. Si une fonction fait trois choses différentes — divisez-la. Si une fonction a plus de 20 lignes — elle peut probablement être divisée. Si une fonction a plus de deux niveaux d’indentation — elle a besoin de refactoring.

Outils de revue de code

Les analyseurs statiques de code sont la première ligne de défense contre le mauvais code. ESLint (JavaScript), Pylint (Python), SonarQube (multilingue), Checkstyle (Java) détectent automatiquement le copier-coller, les nombres magiques, les blocs catch vides, les fonctions trop longues et des centaines d’autres antipatterns.

Les style de code et les formatteurs sont le deuxième niveau de protection. Prettier, Black, gofmt formatent automatiquement le code, éliminant les problèmes d’espaces, d’indentation et de parenthèses. Un style cohérent dans l’équipe rend le code lisible indépendamment de son auteur. Les disputes sur le formatage doivent être automatisées.

La revue de code est le troisième et le plus important niveau. Aucun analyseur ne peut remplacer un humain qui remarque que l’architecture de la solution est erronée ou que le développeur a choisi la mauvaise approche. Une revue efficace prend du temps, mais elle se rentabilise en réduisant considérablement la quantité de mauvais code.

• ESLint — pour JavaScript et TypeScript avec des règles de complexité, max-lines, max-nested-callbacks
• Pylint — pour Python avec des métriques de code et un score de qualité (de -10 à 10)
• SonarQube — pour suivre la dette technique dans le temps
• CodeClimate — pour évaluer l’indice de maintenabilité de chaque fichier
• Better Code Hub — pour vérifier la conformité aux 10 principes du code propre