Que signifie la «complexité cyclomatique» de mon code?
Je suis nouveau dans l'analyse statique du code. Mon application a une complexité cyclomatique de 17 754. L'application elle-même ne compte que 37 672 lignes de code. Est-il valable de dire que la complexité est élevée en fonction des lignes de code? Que me dit exactement la complexité cyclomatique?
Que me dit exactement la complexité cyclomatique?
La complexité cyclomatique n'est pas une mesure de lignes de code, mais le nombre de chemins indépendants à travers un module. Votre complexité cyclomatique de 17 754 signifie que votre application a 17 754 chemins uniques à travers elle. Cela a quelques implications, généralement en termes de difficulté à comprendre et à tester votre application. Par exemple, la complexité cyclomatique est le nombre de cas de test nécessaires pour atteindre une couverture de branche à 100%, en supposant des tests bien écrits.
Un bon point de départ pourrait être le article Wikipedia sur la complexité cyclomatique . Il contient quelques extraits de pseudocode et quelques graphiques qui montrent la complexité cyclomatique. Si vous voulez en savoir plus, vous pouvez lire également l'article de McCabe où il a défini la complexité cyclomatique .
Mon application a une complexité cyclomatique de 17 754 lignes de code. L'application elle-même ne compte que 37 672 lignes de code. Est-il valable de dire que la complexité est élevée en fonction des lignes de code?
Pas du tout. Une application avec peu de lignes de code et un nombre élevé de conditions imbriquées dans des boucles pourrait avoir une complexité cyclomatique extrêmement élevée. D'un autre côté, une application avec peu de conditions peut avoir une faible complexité cyclomatique. Cela simplifie à l'excès, mais je pense que cela fait passer l'idée.
Sans en savoir plus sur ce que fait votre application, il pourrait être normal d'avoir une complexité cyclomatique plus élevée. Je suggérerais toutefois de mesurer la complexité cyclomatique au niveau d'une classe ou d'une méthode, au lieu d'un simple niveau d'application. C'est un peu plus gérable, conceptuellement, je pense - il est plus facile de visualiser ou de conceptualiser les chemins à travers une méthode que les chemins à travers une grande application.
La complexité cyclomatique est un moyen de déterminer si votre code doit être refactorisé. Le code est analysé et un nombre de complexité est déterminé. La complexité est déterminée par ramification (si les instructions, etc.) La complexité peut également prendre en compte l'imbrication des boucles, etc. et d'autres facteurs en fonction de l'algorithme utilisé.
Le nombre est utile au niveau de la méthode. Aux niveaux supérieurs, ce n'est qu'un chiffre.
Un nombre de 17 754 indique la complexité au niveau du projet (code total), ce qui n'a pas beaucoup de sens.
L'exploration de la complexité au niveau des classes et des méthodes déterminera les zones du code qui doivent être refactorisées en méthodes plus petites ou repensées pour éliminer la complexité.
Considérez une instruction CASE avec 50 cas dans une méthode. Peut-être que chaque État a une logique métier différente. Cela va générer une complexité cyclomatique de 50. Il y a 50 points de décision. L'instruction CASE peut devoir être repensée à l'aide d'un modèle d'usine pour se débarrasser de la logique de branchement. Parfois, vous pouvez refactoriser (diviser la méthode en parties plus petites) et dans certains cas, seule une refonte réduira la complexité.
En général, pour la complexité au niveau de la méthode:
- <10 Facile à entretenir
- 11-20 Plus difficile à entretenir
- 21+ candidats pour refactoring/refonte
Considérez également que des complexités plus élevées rendent le code plus difficile à tester unitaire.
La plus grande complexité que j'ai vue sur une seule méthode était 560. Il s'agissait d'environ 2 000 lignes d'instructions if dans une seule méthode. Fondamentalement non maintenable, non testable, plein de bugs potentiels. Imaginez tous les cas de tests unitaires nécessaires pour cette logique de branchement! Pas bon.
Essayez de garder toutes les méthodes sous 20 et réalisez qu'il y a un coût à refactoriser n'importe quelle méthode pour la rendre moins complexe.
C'est le nombre de chemins distincts dans votre application. Consultez cet article IBM sur CC .
Cela semble élevé mais dans votre cas c'est l'ajout du CC de toutes vos méthodes de toutes vos classes et méthodes. Mes exemples sont très étendus car je ne sais pas comment votre code est structuré mais vous pouvez aussi bien avoir une méthode monstre avec 37672 lignes de code ou 3767 méthodes avec environ 10 lignes de code. Ce que je veux dire, c'est qu'au niveau de l'application, cet indicateur ne signifie pas grand-chose, mais au niveau de la méthode, il peut vous aider à optimiser/réécrire votre code dans des méthodes plus petites afin qu'elles soient moins sujettes aux erreurs.
Ce que j'ai personnellement lu plusieurs fois, c'est que les méthodes avec un CC supérieur à 10 présentent des risques de défauts plus élevés.
J'utilise Sonar pour tester la qualité du code de mes applications et par défaut, je pense que cela déclenche un avertissement si vous avez des méthodes avec +10 CC. Cela ne veut toujours rien dire. Un exemple concret: si vous utilisez Eclipse pour générer une méthode equals basée sur les propriétés de votre bean, le CC passera très vite au dessus du toit ...