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 peuvent détecter les cas évidents comme le code après les instructions `return` ou `throw`. Pour les cas plus complexes, utilisez des outils de couverture de code pendant les tests. Le code qui affiche une couverture nulle sur toutes les exécutions de tests pourrait être inaccessible. Examinez chaque cas manuellement car certains codes pourraient être accessibles mais simplement non testés.

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. Cependant, les blocs `finally` s'exécutent toujours, même après un `return`. Erreur courante : placer un nettoyage important 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 ?

Non, car il ne s'exécute jamais. Cependant, il peut référencer des variables non définies ou appeler des fonctions inexistantes sans provoquer d'erreurs, ce qui le rend encore plus insidieux. Ce code défectueux passe tous les tests parce qu'il ne s'exécute jamais, mais il induit en erreur quiconque lit la codebase.

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

Le code derrière des `feature flags` désactivés est accessible à l'exécution (runtime), même s'il est désactivé dans votre environnement actuel. 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 la fonctionnalité soit entièrement supprimée.

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

Oui, mais c'est une catégorie différente de code mort. Le code inaccessible est structurellement impossible à exécuter en raison du flux de contrôle. Les fonctions inutilisées sont accessibles mais jamais appelées. Les deux devraient être supprimés, mais ils nécessitent des stratégies de détection différentes. La détection de code inutilisé requiert une analyse de l'ensemble du programme, tandis que la détection de code inaccessible fonctionne au niveau de la fonction.

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.