Gammes de complexité cyclomatique

Question

Quelles sont les catégories de complexité cyclomatique? Par exemple:

1-5: facile à entretenir
6-10: difficile
11-15: très difficile
20+: approche impossible

Depuis des années, je suis parti de l'hypothèse que 10 était la limite. Et tout ce qui est au-delà est mauvais. J'analyse une solution et j'essaie de déterminer la qualité du code. Certes, la complexité cyclomatique n'est pas la seule mesure, mais elle peut aider. Il existe des méthodes avec une complexité cyclomatique de 200+. Je sais que c'est terrible, mais je suis curieux de connaître les gammes inférieures, comme dans mon exemple ci-dessus.

J'ai trouvé ceci :

Les valeurs de référence susmentionnées de Carnegie Mellon définissent quatre plages approximatives pour les valeurs de complexité cyclomatique:

les méthodes entre 1 et 10 sont considérées comme simples et faciles à comprendre

les valeurs comprises entre 10 et 20 indiquent un code plus complexe, qui peut encore être compréhensible; cependant les tests deviennent plus difficiles à cause du plus grand nombre de branches possibles que le code peut prendre

les valeurs de 20 et plus sont typiques du code avec un très grand nombre de chemins d'exécution potentiels et ne peuvent être pleinement saisies et testées qu'avec beaucoup de difficulté et d'efforts

méthodes allant encore plus haut, par exemple > 50, ne sont certainement pas maintenables

Lors de l'exécution de métriques de code pour une solution, les résultats apparaissent en vert pour tout ce qui est inférieur à 25. Je ne suis pas d'accord avec cela, mais j'espérais obtenir d'autres entrées.

Existe-t-il une liste de plages généralement acceptées pour la complexité cyclomatique?

Robert Harvey · Accepted Answer

Je suppose que cela dépend des capacités de votre personnel de programmation et en grande partie de votre sensibilité en tant que gestionnaire.

Certains programmeurs sont de fervents défenseurs du TDD et n'écriront aucun code sans avoir d'abord écrit un test unitaire. D'autres programmeurs sont parfaitement capables de créer de bons programmes sans bogues sans écrire un seul test unitaire. Le niveau de complexité cyclomatique que chaque groupe peut tolérer va presque certainement varier considérablement.

C'est une métrique subjective; évaluez le paramètre de votre solution Code Metrics et ajustez-le à un endroit idéal avec lequel vous vous sentez à l'aise et qui vous donne des résultats raisonnables.

Arseni Mourzenko · Answer

Il n'y a pas de catégories prédéfinies et aucune catégorisation ne serait possible pour plusieurs raisons:

Certaines techniques de refactoring déplacent simplement la complexité d'un point à un autre (pas du code votre vers le framework ou une bibliothèque externe bien testée, mais d'un emplacement à un autre de la base de code). Cela aide à réduire la complexité cyclomatique et à convaincre votre - boss (ou toute personne qui aime les présentations avec des graphiques en constante augmentation) que vous avez passé votre temps à créer quelque chose de génial, mais le code reste aussi mauvais qu'il l'était auparavant .
Au contraire, parfois, lorsque vous refactorisez un projet en appliquant des modèles de conception et de programmation, la complexité cyclomatique peut empirer, tandis que le code refactorisé devrait être clair: les développeurs connaissent les modèles de programmation (au moins, ils sont censés les connaître), il simplifie donc le code pour eux, mais la complexité cyclomatique n'en tient pas compte.
Certaines autres techniques de non-refactoring n'affectent pas du tout la complexité cyclomatique, tout en diminuant fortement la complexité d'un code pour les développeurs. Exemples: ajout de commentaires ou de documentation pertinents. "Moderniser" le code en utilisant du sucre syntaxique.
Il y a simplement des cas où la complexité cyclomatique n'est pas pertinente. J'aime l'exemple donné par whatsisname dans son commentaire : certaines grandes déclarations switch peuvent être extrêmement claires et les réécrire d'une manière plus OOPy ne serait pas très utile (et compliquerait la compréhension du code par les débutants). En même temps, ces déclarations sont un désastre, en termes de complexité cyclomatique.
Comme Robert Harvey l'a déjà dit ci-dessus , cela dépend de l'équipe elle-même.

En pratique, j'ai vu du code source qui avait une bonne complexité cyclomatique, mais qui était terrible. En même temps, j'ai vu du code à haute complexité cyclomatique, mais je n'ai pas eu trop de mal à le comprendre.

C'est juste que il n'y a pas et ne pourrait pas être un outil qui indiquerait, parfaitement, à quel point bon ou mauvais est un morceau de code donné ou à quel point est-il facile à maintenir . Comme vous ne pouvez pas programmer une application qui dira qu'une peinture donnée est un chef-d'œuvre et qu'une autre doit être jetée, car elle n'a aucune valeur artistique.

Il existe des métriques qui sont brisées par conception (comme LOC ou le nombre de commentaires par fichier), et il existe des métriques qui peuvent donner des indices bruts (comme le nombre de bogues ou la complexité cyclomatique). Dans tous les cas, ce ne sont que des conseils et doivent être utilisés avec prudence.