¿Las expresiones LINQ y Lambda reducen la complejidad ciclomática? Es curioso porque CodeRush realmente muestra una reducción en cc cuando el analizador VS lo aumenta.¿Las expresiones LINQ y Lambda reducen la complejidad de Cyclomatic?
Sospecho que la discrepancia puede deberse a la ejecución diferida. Cuando utiliza LINQ con expresiones lambda, está especificando el código que se ejecutará si itera sobre la colección.
Personalmente no estoy tan preocupado por la complejidad ciclomática, pero estoy absolutamente seguro de que (cuando se usa apropiadamente) LINQ mejora la legibilidad. Eso es lo que yo realmente les importa :)
Acabo de llegar con la misma pregunta y, de hecho, lambda puede aumentar la complejidad ciclomática. Hice la prueba y las cláusulas Where() pueden aumentarlo sensiblemente.
La legibilidad es, de hecho, una de sus principales prioridades.
Pero no tardé en reemplazar algunas consultas LinQ por métodos Get() que me proporcionaron los mismos datos y beneficios adicionales.
guardo mis FXCop en mi build/escritura de publicar lo que nunca despliego algo sin alcanzar el objetivo de 25 para la complejidad ciclomática.
Es difícil, pero creo que vale la pena el esfuerzo.
Esto me otorga algunos puntos en las discusiones cuando mis compañeros vienen con un código muy malo que dice: esto funciona, eso es lo que importa.
mi consejo es: mantener su complejidad ciclomática por debajo de 25. que esto puede ayudar a mantener todos los métodos suficientemente simple para un buen mantenimiento.
Jon Skeet prácticamente respondió la pregunta de manera sucinta. Me gustaría agregar que en mi experiencia con lenguajes de alto nivel como C#, el valor de medir la complejidad ciclomática se reduce debido al valor que los paquetes de azúcar sintáctico como LINQ le agregan al desarrollo. En los últimos diez años, como los idiomas han evolucionado, muchos en la red han ilustrado una fuerte correlación entre la complejidad ciclomática y las líneas de código, haciendo que muchos de ellos se pregunten qué valor realmente aporta esa medida. Otra forma de verlo sería que la devaluación de CC como una medida de la calidad del código es en realidad una afirmación de la importancia de la legibilidad, ya que uno es a menudo el inverso del otro.
Por ejemplo, si pongo un condicional dentro de un bucle foreach, el condicional se evalúa como mi código, y se cuenta el número apropiado de rutas de código. Por otro lado, si aplico un árbol de funciones a la colección sobre la que estoy iterando (por ej., Where (evalStr => evalStr == origStr) muevo el condicional al exterior del bucle y al código generado por el compilador. todavía el mismo número de ramas, sin embargo, los condicionales no son parte del ciclo, sin embargo, el CC aumenta más allá del ciclo foreach, con "penalidades" por usar métodos anónimos (lambdas y delegados) en la parte superior del recuento real de ramas. Donde la función me permite precondicionar la colección iterada para que el ciclo solo itere si es necesario.
Sin embargo, el código es mucho más legible.
Por último, si uno decide que una expresión booleana utilizada dentro de una función LINQ IQueryable no necesita ser probada, aparentemente porque si hay una excepción, es una excepción de orden superior (también conocido como nivel comercial) (incorrecta valor que se prueba, operador incorrecto, operando incorrecto, etc.) en oposición a un uso menos que ideal del lenguaje (usando el interruptor en lugar de si, en vez de ternario, etc.) luego, la medición de la complejidad ciclomática debería tomar esto en cuenta : Una función Where() no debería aumentar mi CC. La medición de la complejidad ciclomática no ayudará a crear un mejor código; en todo caso, aumentará artificialmente la tendencia de un desarrollador a simplificar donde no sea necesaria o deseada la simplificación.