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.
.avif)
