Les expressions LINQ et Lambda réduisent-elles la complexité de Cyclomatic?

Question

Les expressions LINQ et Lambda réduisent-elles la complexité cyclomatique? Juste curieux parce que CodeRush montre en fait une réduction de cc lorsque l’analyseur VS l’augmente.

Answer 1

Je soupçonne que la différence peut être due à une exécution différée. Lorsque vous utilisez LINQ avec des expressions lambda, vous spécifiez le code qui sera exécuté si vous parcourez ensuite la collection.

Personnellement, la complexité cyclomatique ne m'inquiète pas tellement, mais je suis absolument sûr que LINQ (utilisé correctement) améliore la lisibilité. C’est ce qui je tiens vraiment:)

Answer 2

Je viens de poser la même question et, en fait, lambda peut augmenter la complexité cyclomatique. J'ai fait le test et les clauses Where () peuvent augmenter sensiblement.

La lisibilité est l'une de vos priorités.

Mais il ne m'a pas fallu longtemps pour remplacer certaines requêtes LinQ par des méthodes Get () qui m'ont fourni les mêmes données et des avantages supplémentaires.

Je garde mon Fxcop dans mon script de construction / publication afin de ne jamais déployer quelque chose sans atteindre l'objectif de 25 pour la complexité cyclomatique.

C’est difficile, mais je pense que cela en vaut la peine.

Cela me donne quelques points de discussion lorsque mes collègues arrivent avec un très mauvais code disant: ça marche, c'est ce qui compte.

Mon conseil est: maintenez votre complexité cyclomatique en dessous de 25. cela peut vous aider à garder chaque méthode assez simple pour un bon entretien.

Answer 3

Jon Skeet a à peu près répondu à la question succinctement. Je voudrais ajouter que, selon mon expérience des langages de haut niveau tels que C #, la valeur de la mesure de la complexité cyclomatique est réduite en raison de la valeur ajoutée apportée par les paquets de sucre syntaxique tels que LINQ au développement.

Au cours des dix dernières années, au fur et à mesure de l'évolution des langages, de nombreux internautes ont mis en évidence une forte corrélation entre la complexité cyclomatique et les lignes de code. Nombre d'entre eux se demandent alors quelle valeur une telle mesure apporte réellement. Une autre façon de voir les choses serait que la dévaluation de CC en tant que mesure de la qualité du code soit en réalité une affirmation de l’importance de la lisibilité, l’un étant souvent l’inverse de l’autre.

Par exemple, si je mets un conditionnel dans une boucle foreach, le conditionnel est évalué en tant que mon code et le nombre approprié de chemins de code est compté. Par contre, si j’applique une arborescence de fonctions à la collection, j’itère une nouvelle itération (par exemple, Where Il y a toujours le même nombre de branches, bien que les conditionnelles ne fassent pas partie de la boucle, mais le CC augmente au-delà de celui de la boucle foreach, avec & "pénalités &" pour l'utilisation de méthodes anonymes (lambdas La fonction Où me permet de préconditionner la collection itérée afin que la boucle n’itère que si elle en a besoin.

Cependant, le code est de loin plus lisible.

Enfin, si l’on décide qu’une expression booléenne utilisée dans une fonction LINQ IQueryable n’a pas besoin d’être testée à l’unité, ostensiblement, car s’il existe une exception, il s’agit d’une exception d’ordre supérieur (au niveau métier) (valeur incorrecte testé, mauvais opérateur, mauvais opérande, etc.) par opposition à une utilisation moins qu'idéale de la langue (utiliser switch au lieu de if, si au lieu de ternaire, etc.), la mesure de la complexité cyclomatique devrait en tenir compte: Une fonction Where () ne devrait pas augmenter mon CC. Mesurer la complexité cyclomatique ne contribuera pas à créer un meilleur code; au contraire, cela augmentera artificiellement la tendance du développeur à simplifier là où aucune simplification n'est nécessaire ou souhaitée.