Le nombre cyclomatique, la complexité cyclomatique ou la mesure de McCabe est un outil de métrologie logicielle développé par Thomas McCabe en 1976 pour mesurer la complexité d'un programme informatique. Cette mesure reflète le nombre de décisions d'un algorithme en comptabilisant le nombre de « chemins » linéairement indépendants au travers d'un programme représenté sous la forme d'un graphe.
La complexité cyclomatique d'un programme structuré est définie par :
où :
M = complexité cyclomatique ;
E = le nombre d'arêtes du graphe ;
N = le nombre de nœuds du graphe ;
P = le nombre de composantes connexes du graphe.
Un code simple, au faible nombre cyclomatique, est théoriquement plus facile à lire, à tester et à entretenir :
un effort de compréhension plus soutenu doit être effectué durant la lecture d'un code complexe, de façon à retenir et à prendre en compte chaque embranchement ;
les tests unitaires doivent tester toutes les possibilités d’embranchement dans la fonction, de façon à suivre chacun des « chemins » ; or, les tests unitaires ont primordialement été conçus pour tester des fonctions en isolation par un cas simple ;
de même, la correction d'un bug ou l'amélioration d'une fonction simple sera facilitée par l'absence d'obligation de prise en compte de ces embranchements et possibilités.
Cependant, le nombre cyclomatique ne fait pas l'unanimité. Ainsi, dès , une étude montre que le nombre cyclomatique ne s'appuie pas sur une base théorique solide et n'est pas adapté au développement logiciel et souligne qu'aucune observation empirique ne vient justifier l'utilité de cette mesure.
D'autres possibilités existent pour compléter le nombre cyclomatique, comme la complexité NPath (en anglais, NPath complexity), mesurant le nombre total de possibilités d'emprunter l'ensemble des chemins, là où le nombre cyclomatique se contente d'additionner ces chemins.
Notes
Références
Métrique (logiciel)
PMD (logiciel)
Calcul du nombre cyclomatique (article dans MSCoder)
Cyclomatic and NPath complexity explained sur Coding Sw
Cette page est générée automatiquement et peut contenir des informations qui ne sont pas correctes, complètes, à jour ou pertinentes par rapport à votre recherche. Il en va de même pour toutes les autres pages de ce site. Veillez à vérifier les informations auprès des sources officielles de l'EPFL.
En informatique et en particulier en génie logiciel, la qualité logicielle est une appréciation globale d'un logiciel, basée sur de nombreux indicateurs. La complétude des fonctionnalités, la correction et précision des résultats, la fiabilité, la tolérance de pannes, la facilité et la flexibilité de son utilisation, la simplicité, l'extensibilité, la compatibilité et la portabilité, la facilité de correction et de transformation, la performance, la cohérence et l'intégrité des informations qu'il contient sont tous des facteurs de qualité.
Une métrique logicielle est une compilation de mesures issues des propriétés techniques ou fonctionnelles d'un logiciel. Il est possible de classer les métriques logicielles en trois catégories : Maintenance applicative Qualité applicative Respect des processus de développement Elles peuvent être simples ou plus complexes. Elles se composent toujours de mesures dites « de base », par exemple le nombre de lignes de code, la complexité cyclomatique, le nombre de commentaires.
En génie logiciel, la couverture de code est une mesure utilisée pour décrire le taux de code source exécuté d'un programme quand une suite de test est lancée. Un programme avec une haute couverture de code, mesurée en pourcentage, a davantage de code exécuté durant les tests ce qui laisse à penser qu'il a moins de chance de contenir de bugs logiciels non détectés, comparativement à un programme avec une faible couverture de code.
The pursuit of software security and reliability hinges on the identification and elimination of software vulnerabilities, a challenge compounded by the vast and evolving complexity of modern systems. Fuzzing has emerged as an indispensable technique for b ...
Coverage-guided greybox fuzzers rely on control-flow coverage feedback to explore a target program and uncover bugs. Compared to control-flow coverage, data-flow coverage offers a more fine-grained approximation of program behavior. Data-flow coverage capt ...
This Replicating Computational Report (RCR) describes (a) our datAFLow fuzzer and (b) how to replicate the results in "datAFLow: Toward a Data-Flow-Guided Fuzzer." Our primary artifact is the datAFLow fuzzer. Unlike traditional coverage-guided greybox fuzz ...