LINQ e expressões lambda reduzir Cyclomatic complexidade?

Question

LINQ e lambda expressões reduzir cyclomatic complexidade? Apenas curioso porque CodeRush realmente mostra uma redução na cc quando o analisador VS aumenta.

Answer 1

Eu suspeito que a discrepância pode ser devido à execução diferida. Quando você usa LINQ com expressões lambda, você está especificando o código que será executado se então você iterar sobre a coleção.

Pessoalmente eu não estou tão preocupado com a complexidade ciclomática, mas estou absolutamente certo de que (quando usado apropriadamente) LINQ melhora a legibilidade. Isso é o que eu realmente cuidado sobre:)

Answer 2

Eu só vim por aí com a mesma pergunta e, de fato, lambda pode aumentar a complexidade ciclomática. Eu fiz o teste e onde () cláusulas pode aumentá-lo de forma sensata.

Readability é certamente uma das suas principais prioridades.

Mas não demorou muito tempo para substituir algumas consultas LINQ por get () métodos que me fornecidos com os mesmos dados e benefícios extras.

---

Eu mantenho a minha FXCop na minha build / publicar roteiro assim que eu nunca implantar algo sem atingir a meta de 25 para complexidade ciclomática.

É difícil, mas acho que vale a pena o esforço.

Isto concede-me alguns pontos em discussões quando os meus companheiros vêm com um código muito ruim dizendo: isso funciona, é isso que importa.

---

minha dica é: manter sua complexidade ciclomática abaixo de 25 . isso pode ajudar você a manter todos os métodos simples o suficiente para uma boa manutenção.

Answer 3

Jon Skeet praticamente respondeu à pergunta de forma sucinta. Gostaria de acrescentar que, em minha experiência com linguagens de alto nível como C #, o valor de medir a complexidade ciclomática é reduzido por causa do valor que os pacotes de açúcar sintático como LINQ contribui para o desenvolvimento.

Nos últimos anos dez, como línguas evoluíram, muitos na net ilustraram uma forte correlação entre a complexidade e linhas de código cyclomatic, fazendo muitos deles questionar o quanto o valor de uma tal medida, na verdade, traz. Outra maneira de olhar para ele seria a de que a desvalorização do CC como uma medida da qualidade do código é realmente uma afirmação da importância da leitura, como um muitas vezes é o inverso da outra.

Por exemplo, se colocar uma condicional dentro de um loop foreach, o condicional é avaliada como o meu código, e o número apropriado de caminhos de código é contado. Por outro lado, se eu aplicar uma árvore de funções para a coleção Estou iteração sobre (por exemplo, Onde (evalStr => evalStr == origStr) Eu estou movendo o condicional para fora do loop e em código gerado pelo compilador. Há ainda o mesmo número de agências, no entanto as condicionais não fazem parte do circuito, mas os CC aumenta além que do loop foreach, com "penalidades" para o uso de métodos anônimos (lambdas e delegados) no topo da contagem ramo real. o onde função me permite pré-condicionar a coleção iterado até que a alça única itera se ele precisa.

No entanto, o código é de longe mais legível.

Finalmente, se alguém decide que uma expressão booleana usada dentro de uma função LINQ IQueryable não precisa ser unidade testada, ostensivamente porque se há uma exceção, é uma de ordem superior (aka de negócios de nível) exceção (valor errado sendo testado, operador errado, operando errado, etc.), em oposição a um uso menos-que-ideal da língua (com o interruptor em vez de se, se em vez de ternário, etc.), em seguida, medir a complexidade ciclomática deve levar isso em conta: A () função onde não deve aumentar o meu CC. Medindo complexidade ciclomática não vai ajudar a tomar melhores código; se alguma coisa, ele vai aumentar artificialmente tendência de um desenvolvedor para simplificar onde nenhuma simplificação pode ser necessário ou desejado.