Nombre cyclomatique

La complexité cyclomatique d'un programme structuré[note 1] est définie[1] par :

${\displaystyle M=E-N+2P}$

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[2] :

• 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 mars 1988, 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[3].

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[2] - [4].

Notes

Références

• Métrique (logiciel)
• PMD (logiciel)

• Calcul du nombre cyclomatique (article dans MSCoder)
• (en) Cyclomatic and NPath complexity explained sur Coding Swag