Règle
Supprimer commenté code commentés

Commentés code crée du bruit, devient obsolète, 
et appartient dans version contrôle , pas la base de code.

Introduction

Le code commenté s'accumule lorsque les développeurs ne sont pas sûrs d'avoir besoin d'une ancienne logique plus tard. Quelqu'un commente une fonction « au cas où » au lieu de la supprimer, et elle reste là pour toujours. Personne ne sait si ce code fonctionne encore, pourquoi il a été désactivé, ou s'il est sûr de le supprimer. La base de code se remplit de fantômes d'anciennes implémentations qui détournent l'attention de la compréhension de ce qui s'exécute réellement en production.

Pourquoi c'est important

Maintenabilité du code : Le code commenté force les lecteurs à filtrer mentalement ce qui est réel de ce qui est inactif. Lors de la revue de code, il est impossible de savoir si ces blocs sont des expériences temporaires, des options de retour arrière importantes ou des vestiges oubliés d'il y a des années. Ce bruit rend plus difficile la compréhension de la logique réelle, la recherche de sections de code pertinentes et la revue des modifications de manière significative.

Implications de sécurité : Les vérifications d'authentification, la logique de validation ou les fonctionnalités de sécurité mises en commentaire révèlent que ces protections existaient mais ont été délibérément désactivées. Si le code commenté contient des identifiants, des clés API ou des URL internes, vous livrez ces données sensibles en texte clair. Les attaquants qui examinent votre base de code voient exactement quelles mesures de sécurité vous avez envisagées et supprimées.

Confusion du contrôle de version : Les diffs Git sont encombrés de blocs commentés qui ne changent pas réellement. Lorsque vous devez retracer quand une logique a changé ou pourquoi une fonctionnalité fonctionne d'une certaine manière, les alternatives commentées masquent l'historique réel. La recherche dans la base de code renvoie des correspondances dans du code mort, ce qui fait perdre du temps à investiguer des chemins qui ne s'exécutent pas.

Exemples de code

❌ Non conforme :

async function createUser(userData) {
    // const hashedPassword = await bcrypt.hash(userData.password, 10);

    const user = await db.users.create({
        email: userData.email,
        password: userData.password,
        // password: hashedPassword,
        role: userData.role || 'user'
    });

    // await sendWelcomeEmail(user.email);
    // await notifyAdmins(user);

    // Old validation approach
    // if (!isValidEmail(user.email)) {
    //     throw new Error('Invalid email');
    // }

    return user;
}

Pourquoi c'est incorrect : Le hachage de mot de passe commenté révèle que les mots de passe sont stockés en clair, une vulnérabilité de sécurité critique. Personne ne sait si l'e-mail de bienvenue et la notification admin doivent être activés, et l'ancienne validation suggère que la validation d'e-mail pourrait être manquante.

✅ Conforme :

async function createUser(userData) {
    if (!isValidEmail(userData.email)) {
        throw new Error('Invalid email');
    }

    const hashedPassword = await bcrypt.hash(userData.password, 10);

    const user = await db.users.create({
        email: userData.email,
        password: hashedPassword,
        role: userData.role || 'user'
    });

    await sendWelcomeEmail(user.email);
    await notifyAdmins(user);

    return user;
}

Pourquoi c'est important : La fonction est claire et complète, montrant exactement ce qui s'exécute en production. La validation des e-mails s'exécute en premier, les mots de passe sont correctement hachés, et toutes les notifications sont envoyées sans ambiguïté sur ce qui est activé.

Conclusion

Supprimez le code au lieu de le commenter. Votre système de contrôle de version préserve chaque ligne jamais écrite, accessible via git log et git blame lorsque vous en avez besoin. Conserver du code commenté dans le dépôt ne fait que créer du bruit qui obscurcit la logique réelle et rend votre base de code plus difficile à naviguer.