Le espressioni LINQ e Lambda riducono la complessità ciclomatica?

Question

Le espressioni LINQ e Lambda riducono la complessità ciclomatica? Solo curioso perché CodeRush mostra in realtà una riduzione di cc quando l'analizzatore VS lo aumenta.

Answer 1

Sospetto che la discrepanza possa essere dovuta a un'esecuzione differita. Quando usi LINQ con le espressioni lambda, specifichi il codice che verrà eseguito se esegui l'iterazione della raccolta.

Personalmente non sono così preoccupato per la complessità ciclomatica, ma sono assolutamente sicuro che (se usato in modo appropriato) LINQ migliora la leggibilità. Questo è ciò di cui veramente mi preoccupo :)

Answer 2

Sono appena arrivato con la stessa domanda e, in effetti, la lambda può aumentare la complessità ciclomatica. Ho fatto il test e le clausole Where () possono aumentarlo sensibilmente.

La leggibilità è in effetti una delle tue massime priorità.

Ma non mi ci è voluto molto per sostituire alcune query LinQ con i metodi Get () che mi hanno fornito gli stessi dati e vantaggi extra.

---

Continuo a utilizzare Fxcop nel mio script di compilazione / pubblicazione in modo da non distribuire mai qualcosa senza raggiungere l'obiettivo di 25 per la complessità ciclomatica.

È difficile, ma penso che ne valga la pena.

Questo mi concede alcuni punti nelle discussioni quando i miei compagni arrivano con un pessimo codice che dice: funziona, ecco cosa conta.

---

il mio consiglio è: mantenere la complessità ciclomatica al di sotto di 25. questo può aiutarti a mantenere ogni metodo abbastanza semplice per una buona manutenzione.

Answer 3

Jon Skeet ha praticamente risposto alla domanda in modo succinto. Vorrei aggiungere che nella mia esperienza con linguaggi di alto livello come C #, il valore della misurazione della complessità ciclomatica è ridotto a causa del valore che i pacchetti di zucchero sintattico come LINQ aggiungono allo sviluppo.

Negli ultimi dieci anni, con l'evolversi delle lingue, molti sulla rete hanno illustrato una forte correlazione tra complessità ciclomatica e linee di codice, facendo in modo che molti di loro si chiedano quanto valore appaia effettivamente tale misura. Un altro modo di vedere sarebbe che la svalutazione di CC come misura della qualità del codice è in realtà un'affermazione dell'importanza della leggibilità, poiché l'una è spesso l'inverso dell'altra.

Ad esempio, se inserisco un condizionale all'interno di un ciclo foreach, il condizionale viene valutato come mio codice e viene conteggiato il numero appropriato di percorsi di codice. D'altra parte, se applico un albero delle funzioni alla raccolta su cui sto ripetendo (ad es. Where (evalStr = & Gt; evalStr == origStr) sto spostando il condizionale all'esterno del ciclo e in un compilatore generato codice. C'è ancora lo stesso numero di rami, tuttavia i condizionali non fanno parte del ciclo, tuttavia il CC aumenta oltre quello del ciclo foreach, con " penalità " per l'utilizzo di metodi anonimi (lambdas e delegati) oltre al conteggio dei rami effettivi. La funzione Where mi consente di precondizionare la raccolta ripetuta in modo che il ciclo esegua l'iterazione solo se necessario.

Tuttavia, il codice è di gran lunga più leggibile.

Infine, se si decide che un'espressione booleana utilizzata all'interno di una funzione LINQ IQueryable non ha bisogno di essere testata dall'unità, apparentemente perché se c'è un'eccezione, si tratta di un'eccezione di ordine superiore (aka livello aziendale) (valore errato in fase di test, operatore errato, operando sbagliato, ecc.) rispetto a un uso tutt'altro che ideale della lingua (usando switch invece di if, if invece di ternary, ecc.) quindi misurare la complessità ciclomatica dovrebbe tenerne conto: Una funzione Where () non dovrebbe aumentare il mio CC. Misurare la complessità ciclomatica non aiuterà a rendere il codice migliore; semmai aumenterà artificialmente la tendenza di uno sviluppatore a semplificare laddove non sia possibile o desiderata alcuna semplificazione.