Aikido

Comment identifier et supprimer le code mort inaccessible

Lisibilité

Règle
Supprimer les morts code
Code inaccessible est est confus, 
et impossible à tester, et devrait être supprimé.

Langues prises en charge : 45+

Introduction

Le code inaccessible signale une logique défaillante dans votre base de code. Code après retour ou lancer des instructions ont été écrites pour s'exécuter mais ne s'exécutent jamais. Des conditions toujours fausses masquent des validations ou des gestions d'erreurs qui ne se déclenchent jamais. Des branches que la logique n'atteint jamais en raison du flux de contrôle contiennent des fonctionnalités qui ne peuvent pas s'exécuter. Lorsque vous trouvez du code inaccessible, vous avez trouvé un bug où votre code ne fait pas ce qu'il était censé faire.

Pourquoi c'est important

Vulnérabilités de sécurité : Les contrôles de sécurité inaccessibles ne protègent pas votre application. Si l'authentification, l'autorisation ou la validation des entrées apparaît après un retour instruction, votre code semble sécurisé mais ne l'est pas. Les attaquants peuvent exploiter des fonctions qui semblent avoir des mesures de sécurité mais les contournent en réalité. L'analyse de code pourrait manquer ces vulnérabilités car la logique de sécurité existe dans la base de code, mais ne s'exécute jamais.

Bugs logiques en production : Le code mort signifie que votre fonction n'implémente pas la logique que vous pensez. Une validation qui ne s'exécute jamais laisse passer des données invalides. Une gestion des erreurs inaccessible signifie que les erreurs se propagent sans être interceptées. Les règles métier contournées produisent des résultats incorrects. Le code semble correct mais se comporte différemment de ce qui est prévu.Lacunes de test : Le code inaccessible ne peut pas être testé. Si votre suite de tests passe malgré l'inaccessibilité de code critique, cela signifie que vous n'avez pas de tests couvrant ces chemins. Le code inaccessible révèle des lacunes dans votre couverture de tests où une logique importante existe mais n'a pas de tests vérifiant son exécution.

Impact sur la taille du bundle : Le code inaccessible est toujours livré aux utilisateurs comme un poids mort dans votre bundle JavaScript. Les utilisateurs téléchargent et analysent du code qui ne s'exécute jamais, mais cela est secondaire par rapport aux bugs logiques que le code mort indique.

Exemples de code

❌ Non conforme :

function transferFunds(fromAccount, toAccount, amount) {
    if (!fromAccount || !toAccount) {
        return { success: false, error: 'Invalid accounts' };
    }

    if (amount <= 0) {
        return { success: false, error: 'Invalid amount' };
        logSuspiciousActivity(fromAccount, amount);
    }

    const balance = getBalance(fromAccount);
    if (balance >= amount) {
        deductFunds(fromAccount, amount);
        addFunds(toAccount, amount);
        return { success: true };
    }

    return { success: false, error: 'Insufficient funds' };

    // Check for fraud patterns
    if (isHighRiskTransaction(fromAccount, toAccount, amount)) {
        notifyFraudTeam(fromAccount, toAccount, amount);
        return { success: false, error: 'Transaction blocked' };
    }
}

Pourquoi c'est incorrect : La logique de détection de fraude ne s'exécute jamais car la fonction retourne avant de l'atteindre. L'enregistrement des activités suspectes après la vérification du montant ne s'exécute jamais non plus. Cette fonction semble avoir des mesures de sécurité mais traite en fait tous les transferts sans vérification de fraude.

✅ Conforme :

function transferFunds(fromAccount, toAccount, amount) {
    if (!fromAccount || !toAccount) {
        return { success: false, error: 'Invalid accounts' };
    }

    if (amount <= 0) {
        logSuspiciousActivity(fromAccount, amount);
        return { success: false, error: 'Invalid amount' };
    }

    if (isHighRiskTransaction(fromAccount, toAccount, amount)) {
        notifyFraudTeam(fromAccount, toAccount, amount);
        return { success: false, error: 'Transaction blocked' };
    }

    const balance = getBalance(fromAccount);
    if (balance >= amount) {
        deductFunds(fromAccount, amount);
        addFunds(toAccount, amount);
        return { success: true };
    }

    return { success: false, error: 'Insufficient funds' };
}

Pourquoi c'est important : Toutes les vérifications de sécurité s'exécutent avant le traitement du transfert. La détection de fraude s'exécute sur chaque transaction. Toute activité suspecte est journalisée. La fonction implémente la logique de sécurité qu'elle est censée avoir.

Conclusion

Le code inaccessible indique des bugs dans votre logique où la fonctionnalité prévue ne s'exécute jamais. Trouvez-le avec des outils d'analyse statique dans votre pipeline CI et traitez-le comme un problème critique, pas seulement comme un nettoyage de code. Lorsque vous découvrez du code inaccessible, enquêtez sur sa raison d'être et sur la logique qui était censée s'exécuter mais ne le fait pas.

FAQ

Des questions ?

Comment identifier le code inaccessible dans les bases de code volumineuses ?

Les outils d'analyse statique détectent les cas évidents comme le code après les instructions `return` ou `throw`. Pour les cas complexes, utilisez des outils de couverture de code pendant les tests. Le code affichant une couverture nulle sur des suites de tests complètes est probablement inaccessible, bien que vous deviez vérifier manuellement car il pourrait simplement être non testé.

Qu'en est-il du code après les retours anticipés dans les blocs try-catch ?

Le code après un `return` dans un bloc `try` mais avant un `finally` est inaccessible. Le bloc `finally` s'exécute toujours, même après un `return`. Une erreur courante consiste à placer le code de nettoyage après un `return` dans un bloc `try` au lieu de le mettre dans le bloc `finally` où il s'exécuterait réellement.

Un code inaccessible peut-il provoquer des erreurs d'exécution ?

Le code inaccessible EST l'erreur. Cela signifie qu'une logique critique qui devrait s'exécuter ne le fait pas. Si votre code inaccessible contient des validations, des contrôles de sécurité ou de la gestion d'erreurs, votre fonction est défaillante même si elle ne lève pas d'exceptions. Le bug est que la fonctionnalité prévue ne s'exécute jamais, et non que le code inaccessible provoque un crash.

Qu'en est-il des feature flags et de la compilation conditionnelle ?

Le code derrière des `feature flags` désactivés reste accessible à l'exécution (runtime), même s'il est désactivé dans votre environnement. Un code véritablement inaccessible est structurellement impossible à exécuter en raison du flux de contrôle. Le code sous `feature flag` est conditionnellement accessible et devrait rester jusqu'à ce que vous supprimiez complètement la fonctionnalité.

Dois-je supprimer les fonctions et imports inutilisés ?

Oui, mais c'est un problème différent. Le code inaccessible est structurellement impossible à exécuter au sein de sa fonction en raison du flux de contrôle. Les fonctions inutilisées sont appelables mais jamais invoquées. Les deux gaspillent des ressources, mais elles nécessitent des stratégies de détection différentes. La détection de code inaccessible fonctionne au niveau de la fonction, tandis que la détection de code inutilisé requiert une analyse de l'ensemble du programme.

Sécurisez-vous maintenant.

Sécuriser votre code, votre cloud et votre runtime dans un système centralisé unique.
Détectez et corrigez les vulnérabilités rapidement et automatiquement.

Pas de carte de crédit requise | Résultats du scan en 32 secondes.