¿Las expresiones LINQ y Lambda reducen la complejidad ciclomática?

Question

¿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.

Answer 1

Sospecho que la discrepancia puede deberse a una ejecución diferida. Cuando usa LINQ con expresiones lambda, está especificando el código que se ejecutará si luego itera sobre la colección.

Personalmente, no estoy tan preocupado por la complejidad ciclomática, pero estoy absolutamente seguro de que (cuando se usa adecuadamente) LINQ mejora la legibilidad. Eso es lo que realmente me importa :)

Answer 2

Acabo de darme la misma pregunta y, de hecho, lambda puede aumentar la complejidad ciclomática. Hice la prueba y las cláusulas Where () pueden aumentarla sensiblemente.

La legibilidad es una de sus principales prioridades.

Pero no me llevó mucho tiempo reemplazar algunas consultas de LinQ por métodos Get () que me proporcionaron los mismos datos y beneficios adicionales.

---

Mantengo mi Fxcop en mi script de compilación / publicación, por 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: mantenga su complejidad ciclomática por debajo de 25. esto puede ayudarlo a mantener todos los métodos lo suficientemente simples para un buen mantenimiento.

Answer 3

Jon Skeet respondió la pregunta sucintamente. 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ácticos como LINQ agregan al desarrollo.

Durante los últimos diez años, a medida que 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, lo que hace que muchos de ellos cuestionen cuánto valor aporta realmente 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 una es a menudo inversa a la otra.

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 en la que estoy iterando (por ejemplo, Where (evalStr = & Gt; evalStr == origStr), estoy moviendo el condicional al exterior del bucle y al compilador generado código. Todavía hay el mismo número de ramas, sin embargo, los condicionales no son parte del bucle, pero el CC aumenta más allá del bucle foreach, con & "; penalizaciones &"; por usar métodos anónimos (lambdas y delegados) en la parte superior del conteo de rama real. La función Where me permite preacondicionar la colección iterada para que el ciclo solo se repita si es necesario.

Sin embargo, el código es mucho más legible.

Finalmente, si uno decide que una expresión booleana utilizada dentro de una función LINQ IQueryable no necesita ser probada por unidad, aparentemente porque si hay una excepción, es una excepción de orden superior (también conocido como nivel comercial) (valor incorrecto prueba, operador incorrecto, operando incorrecto, etc.) en lugar de un uso del lenguaje menos que ideal (usando el interruptor en lugar de if, if en lugar de ternary, etc.), entonces la medición de la complejidad ciclomática debe tener esto en cuenta: Una función Where () no debería aumentar mi CC. Medir 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.