Quelle est votre/une bonne limite pour la complexité cyclomatique ?

Question

Nos clients ont commencé à imposer des exigences de complexité cyclomatique aux logiciels de nos produits, et notre groupe interne d'"amélioration" des processus a décidé d'intégrer la complexité cyclomatique dans nos normes de codage. Le client et notre groupe interne ont fixé leur (recommandation pour une) limite supérieure à 10. J'ai fait valoir que si 10 est la recommandation/ligne directrice, les développeurs écriront du code qui atteint 15 ou 20. À mon avis, la limite devrait être fixée à 5, avec la possibilité pour les fonctions de dépasser cette limite si nécessaire (comme déterminé par la révision ou un autre processus).

Donc, ma question est : que font les autres ? Quelles sont les limites de complexité que vous êtes prêts à tolérer (élevées ou faibles) ? Que recherchez-vous lorsque vous écrivez du code ?

Mise à jour : Je parle de la complexité au niveau des fonctions.

L'une des réponses dit : "sans partager tous les détails, le mieux que vous puissiez obtenir ici est une limite arbitraire." J'irais un peu plus loin en disant que les limites arbitraires sont essentiellement ce dont nous parlons. Dans l'intérêt de faire avancer la conversation, cependant, quels détails spécifiques changeraient la réponse ? Qu'est-ce qui, en général, ferait que ces limites soient augmentées ou diminuées ?

Answer 1

Selon le document suivant (et j'ai lu que quelqu'un d'autre avant): http://www.mccabe.com/pdf/MeasuringSoftwareComplexityUAV.pdf Une limite à droite est d'environ 11 (voir p3 de la doc), la CC et la probabilité d'avoir des bug sont liés et semblent croix à ce niveau de la CC.

Et il semble tout à fait logique pour moi, l'abaissement de la CC vous suffit de déplacer la complexité du code "quelque chose" d'autre. La complexité n'est pas tout simplement disparaître.

Dans un langage OO, vous pouvez réduire le CC par la création de plusieurs classes, mais cela affecte un autre code de mesure de la qualité, par exemple: nombre de classes et/ou le niveau de l'héritage qui doit être limitée.

Vous devez prendre en compte tous les code de mesures de la qualité, pas seulement un.

Answer 2

Nous utilisons un ensemble de seuils rouge/jaune/vert. Chacun de ces seuils comporte des règles spécifiques concernant le moment où un réviseur est censé signaler la modification, généralement en fonction de la "couleur" du code avant, et de la couleur vers laquelle il va évoluer avec les modifications proposées.

Cependant, nous travaillons sur une base de code héritée. Nous avons mesuré le code existant, puis nous avons défini des seuils raisonnables qui nous permettraient d'aller de l'avant sans révolte des développeurs. Je crois que nos seuils se situent autour de 5-8 pour le vert/jaune et 8-10 pour le jaune/rouge.

Notez que Le SEI définit des seuils (p.147), mais ils semblent être beaucoup plus indulgents. Je suis d'accord avec vous pour dire qu'une valeur proche de 5 à 10 est saine et que toute valeur supérieure est un signal d'alarme.

Answer 3

Si une fonction représente plus d'un écran de code, cela déclenche des alarmes mentales pour moi. Postez les conditions une fois que la fonction est terminée.

• C'est aussi court que possible.
• Il est aussi lisible que possible, c'est-à-dire qu'il communique l'intention.

Je ne m'inquiète pas trop de la complexité du calcul... trop complexe pour moi.

Answer 4

Si vous écrivez votre code avec une approche TDD, vous pouvez constater que le code résultant a une moyenne d'environ 3. En utilisant le TDD, j'obtiens rarement des méthodes monstrueuses avec des instructions switch géantes (qui augmentent le CC avec chaque instruction case :).

D'un point de vue organisationnel, il n'y a pas d'exigences sur le CC pour nous. Personnellement, si je vois une méthode avec plus de 5, j'essaie de la réduire, si possible.

Answer 5

Selon Code Complete de Steve McConnell, une complexité cyclomatique comprise entre 0 et 5 indique que la routine est "probablement bonne", à une complexité de 6-10, vous devriez commencer à réfléchir à des moyens de simplifier la routine, et à une complexité de plus de 10, vous devriez casser une partie de la routine dans une deuxième routine.

Il convient de noter que le simple fait de déplacer la complexité dans une nouvelle routine ne réduit pas la complexité cyclomatique de l'application dans son ensemble. Cependant, cela permet de mieux comprendre et de travailler avec des blocs plus petits.

Il est également important de comprendre qu'il ne s'agit pas de limites strictes, mais plutôt de signaux d'alerte. Ce n'est pas parce qu'une méthode a une complexité cyclomatique de 10 que c'est une bonne idée de la décomposer.