Trouvez-vous la complexité cyclomatique une mesure utile?
j'ai essayé de mesurer la complexité cyclomatique d'une grande base de code.
la complexité cyclomatique est le nombre de chemins linéairement indépendants à travers le code source d'un programme et il y a beaucoup d'outils gratuits pour la langue de votre choix.
les résultats sont intéressants mais pas surprenants. Qui est, les pièces que je sais être bien poilue étaient en fait les plus complexes (avec une cote de > 50). Mais ce que je trouve utile est qu'un numéro de "méchanceté" concret est assigné à chaque méthode comme quelque chose que je peux indiquer au moment de décider où commencer le remaniement.
utilisez-vous la complexité cyclomatique? Quel est le code le plus complexe que vous ayez trouvé?
15 réponses
nous remanions impitoyablement, et utilisons la complexité cyclomatique comme une des mesures qui obtient le code sur notre 'liste de succès'. 1-6 nous ne marquons pas pour la complexité (bien qu'elle puisse être remise en question pour d'autres raisons), 7-9 est discutable, et toute méthode supérieure à 10 est supposé être mauvais sauf preuve contraire.
le pire que nous ayons vu était 87 d'une chaîne si-sinon-si monstrueuse dans un code d'héritage que nous avons dû prendre en charge.
en fait, la complexité cyclomatique peut être utilisée au-delà des seuils du niveau de la méthode. Pour commencer, une grande méthode avec une grande complexité peut être divisé en plusieurs petites méthodes avec une plus faible complexité. Mais il a vraiment amélioré la base de code? Certes, vous pouvez obtenir un peu plus de lisibilité par tous ces noms de méthode. Mais la logique conditionnelle totale n'a pas changé. Et la logique conditionnelle totale peut souvent être réduite de en remplaçant les conditionnels par du polymorphisme .
nous avons besoin d'une métrique qui ne vire pas au vert par simple décomposition. Je l'appelle CC100 .
CC100 = 100 * (Total complexité cyclomatique de la base de code) / (Total des lignes de code)
c'est utile pour moi de la même manière que big-O est utile: je sais ce que c'est, et je peux l'utiliser pour avoir une intuition pour savoir si une méthode est bonne ou mauvaise, mais je n'ai pas besoin de la calculer pour chaque fonction que j'ai écrite.
je pense que des mesures plus simples, comme LOC, sont au moins aussi bonnes dans la plupart des cas. Si une fonction ne s'adapte pas sur un écran, peu importe sa simplicité. Si une fonction prend 20 paramètres et fait 40 variables locales, il n'a pas d'importance si son la complexité cyclomatique est 1.
Nous avons récemment commencé à l'utiliser. Nous utilisons NDepend pour faire une analyse de code statique, et il mesure la complexité cyclomatique. Je suis d'accord, c'est une bonne façon d'identifier les méthodes pour le remaniement.
Malheureusement, nous avons vu #'s au-dessus de 200 pour certaines méthodes créées par nos développeurs offshore.
Jusqu'à ce qu'il y ait un outil qui peut bien fonctionner avec les modèles C++, et les techniques de méta-programmation, il n'est pas beaucoup d'aide dans ma situation. Quoi qu'il en soit, rappelez-vous que
"toutes les choses qui peuvent être mesuré, et pas tout ce qui peut être mesurée comte" Einstein
donc n'oubliez pas de transmettre toute information de ce type par le filtrage humain aussi.
tu connaîtras la complexité quand tu la verras. La principale chose pour laquelle ce genre d'outil est utile est de signaler les parties du code qui échappaient à votre attention.
je mesure souvent la complexité cyclomatique de mon code. J'ai trouvé que ça m'aide à repérer les zones de code qui en font trop. Avoir un outil pointer les points chauds dans mon code est beaucoup moins de temps que d'avoir à lire à travers des milliers de lignes de code en essayant de comprendre quelles méthodes ne suivent pas la SRP.
cependant, j'ai trouvé que lorsque je fais une analyse de complexité cyclomatique sur le code d'autres personnes, il conduit généralement à des sentiments de frustration, angst, et la colère générale quand je trouve le code avec la complexité cyclomatique dans les 100's. Qu'est-ce qui oblige les gens à écrire des méthodes qui ont plusieurs milliers de lignes de code en eux?!
c'est excellent pour aider à identifier les candidats pour le remaniement, mais il est important de garder votre jugement autour. Je soutiendrais les gammes kenj0418 pour l'élagage des guides.
il y a une métrique Java appelée CRAP4J qui combine empiriquement la complexité cyclomatique et la couverture de test de JUnit pour arriver à une métrique unique. Il fait des recherches pour essayer d'améliorer sa formule empirique. Je ne suis pas sûr de savoir comment il est répandu.
Je ne l'ai pas utilisé depuis un moment, mais sur un projet précédent, il a vraiment aidé à identifier les points de trouble potentiels dans le code de quelqu'un elses (ne serait pas le mien, bien sûr!)
après avoir trouvé le secteur à vérifier, j'ai rapidement trouvé de nombreux problèmes (aussi beaucoup de GOTO vous croiriez!) avec une logique et un code WTF très étrange.
la complexité cyclomatique est grande pour montrer les zones qui font probablement beaucoup et donc briser le unique responsabilité prinicpal. Ces fonctions devraient idéalement être divisées en fonctions multiples
+1 pour les valeurs de la liste des hits de kenj0418.
le pire que j'ai vu était un 275. Il y en avait deux autres de plus de 200 que nous avons été en mesure de refactoriser vers le bas vers des CCs beaucoup plus petits; ils étaient encore élevés, mais ils ont été repoussés plus loin dans la ligne. Nous n'avons pas eu beaucoup de chance avec la bête 275 -- c'était (c'est probablement encore) un réseau de si - et de switch-statements qui était juste beaucoup trop complexe. Ce n'est que la valeur réelle est comme une étape-par quand ils décident de reconstruire le système.
les exceptions au CC élevé avec lequel j'étais à l'aise étaient les usines; IMO, ils sont censés avoir un CC élevé, mais seulement s'ils ne font que la création et le retour d'objet simple.
Après compréhension ce que cela signifie, j'ai maintenant commencé à l'utiliser sur un "procès". Jusqu'à présent, je l'ai trouvé utile , parce que généralement haut CC va main dans la main avec le Flèche Anti-modèle , ce qui rend le code plus difficile à lire et à comprendre. Je n'ai pas encore de numéro fixe, mais NDepend avertit pour tout ce qui est au-dessus de 5, ce qui semble être un bon début pour étudier les méthodes.
Oui, nous l'utilisons et je trouve qu'il est utile aussi. Nous avons une grande base de code héritage à apprivoiser et nous avons trouvé alaraming haute complexité cyclomatique. (387 en une seule méthode!). CC vous indique directement les domaines qui valent la peine d'être remaniés. Nous utilisons CCCC sur le code C++.
la complexité cyclomatique n'est qu'un composant de ce que l'on pourrait appeler la complexité fabriquée. Un temps, j'ai écrit un article pour résumer plusieurs dimensions de la complexité de code: La Lutte Contre Fabriqués Complexité
L'outillageest nécessaire pour gérer efficacement la complexité du code. L'outil NDepend pour code. Net vous permettra d'analyser de nombreuses dimensions de la complexité du code, y compris les paramètres de code comme: Cyclomatique Complexité, profondeur de nidification, manque de cohésion des méthodes, couverture par des Tests...
incluant l'analyse des dépendances et incluant un langage ( Code Query Language ) dédié à demander, qu'est-ce qui est complexe dans mon code, et à écrire la règle?