Condividi tramite


Metriche del codice - Complessità ciclomatica

Quando si lavora con le metriche del codice, uno degli elementi meno compresi sembra essere la complessità ciclomatica. Essenzialmente, con complessità ciclomatica, i numeri più alti sono cattivi e i numeri inferiori sono buoni. È possibile usare la complessità ciclomatica per ottenere un'idea di quanto sia difficile qualsiasi codice specifico per testare, gestire o risolvere i problemi, nonché un'indicazione della probabilità che il codice produrrà errori. A livello generale, si determina il valore della complessità ciclomatica conteggiando il numero di decisioni prese nel codice sorgente. In questo articolo si inizia con un semplice esempio di complessità ciclomatica per comprendere rapidamente il concetto, quindi esaminare alcune informazioni aggiuntive sull'utilizzo effettivo e sui limiti suggeriti. Infine, c'è una sezione di citazioni che possono essere usate per approfondire questo argomento.

Esempio

La complessità ciclomatica è definita come misurazione della "quantità di logica decisionale in una funzione del codice sorgente" NIST235. In poche parole, più decisioni devono essere prese nel codice, più complesse è.

Vediamolo in azione. Creare una nuova applicazione console e calcolare immediatamente le metriche del codice andando su Analizzare, poi > Calcolare le metriche del codice per la soluzione.

l'esempio di complessità ciclomatica 1

Si noti che la complessità ciclomatica è a 2 (il valore più basso possibile). Se si aggiunge codice non decisionale, si noti che la complessità non cambia:

complessità ciclomatica esempio 2

Se si aggiunge una decisione, il valore della complessità ciclomatica aumenta di uno:

complessità ciclomatica esempio 3

Quando si modifica l'istruzione if in un'istruzione switch con quattro decisioni da prendere, passa dai due originali ai sei:

esempio di complessità ciclomatica 4

Esaminiamo una codebase (ipotetica) più grande.

esempio di complessità ciclomatica 5

Nota che la maggior parte degli elementi, mentre approfondisci nella classe Products_Related, ha un valore di uno, ma un paio di essi hanno una complessità di cinque. Da solo, questa differenza potrebbe non essere un grosso problema, ma dato che la maggior parte degli altri membri hanno uno nella stessa classe, si dovrebbe sicuramente esaminare più da vicino questi due elementi e vedere cosa è in essi. È possibile dare un'occhiata più da vicino facendo clic con il pulsante destro del mouse sull'elemento e scegliendo Vai al codice sorgente dal menu di scelta rapida. Esaminare più in dettaglio Product.set(Product):

esempio di complessità ciclomatica 6

Date tutte le istruzioni if, si può vedere perché la complessità ciclomatica è pari a cinque. A questo punto, è possibile decidere che questo risultato è un livello accettabile di complessità oppure è possibile effettuare il refactoring per ridurre la complessità.

Il numero magico

Come per molte metriche in questo settore, non esiste un limite esatto di complessità ciclomatica adatto a tutte le organizzazioni. Tuttavia, NIST235 indica che un limite di 10 è un buon punto di partenza:

"Il numero preciso da usare come limite, tuttavia, rimane un po 'controverso. Il limite originale di 10 come proposto da McCabe ha prove di supporto significative, ma limiti fino a 15 sono stati utilizzati con successo. I limiti superiori a 10 devono essere riservati ai progetti che presentano diversi vantaggi operativi rispetto ai progetti tipici, ad esempio personale esperto, progettazione formale, linguaggio di programmazione moderno, programmazione strutturata, procedure dettagliate del codice e un piano di test completo. In altre parole, un'organizzazione può scegliere un limite di complessità maggiore di 10, ma solo se è sicuro di sapere cosa sta facendo ed è disposto a dedicare il lavoro di test aggiuntivo richiesto da moduli più complessi." NIST235

Complessità ciclomatica e numeri di riga

Considerare esclusivamente il numero di righe di codice rappresenta, nella migliore delle ipotesi, un indicatore molto generico della qualità del codice. C'è una certa verità di base per l'idea che più righe di codice in una funzione, più è probabile che si verifichino errori. Tuttavia, quando si combina la complessità ciclomatica con righe di codice, si ha un quadro molto più chiaro del potenziale di errori.

Come descritto dal Software Assurance Technology Center (SATC) alla NASA:

"Il SATC ha trovato che la valutazione più efficace è data da una combinazione di dimensioni e complessità ciclomatica." I moduli con complessità elevata e dimensioni elevate tendono ad avere l'affidabilità più bassa. I moduli con dimensioni basse e complessità elevata rappresentano anche un rischio di affidabilità perché tendono a essere codice molto conciso, che è difficile da cambiare o modificare." SATC

Analisi del codice

L'analisi del codice include una categoria di regole di gestibilità. Per altre informazioni, vedere Regole di manutenibilità. Quando si usa l'analisi del codice legacy, il set di regole delle linee guida per la progettazione estesa contiene un'area di gestibilità:

set di regole per la progettazione della complessità ciclomatica

All'interno dell'area di manutenibilità vi è una regola per la complessità:

regola di mantenibilità della complessità ciclomatica

Questa regola genera un avviso quando la complessità ciclomatica raggiunge 25, in modo da evitare una complessità eccessiva. Per altre informazioni sulla regola, vedere CA1502

Mettere tutto insieme

In definitiva, un alto livello di complessità significa una maggiore probabilità di errori, il che richiede più tempo per la manutenzione e la risoluzione dei problemi. Esaminare in modo più approfondito le funzioni con una complessità elevata e decidere se eseguire il refactoring per renderle meno complesse.

Citazioni

MCCABE5

McCabe, T. e A. Watson (1994), Complessità software (CrossTalk: The Journal of Defense Software Engineering).

NIST235

Watson, A. H., & McCabe, T. J. (1996). Test strutturati: metodologia di test che usa la metrica di complessità ciclomatica (pubblicazione speciale NIST 500-235). Recuperato il 14 maggio 2011 dal sito Web McCabe Software: http://www.mccabe.com/pdf/mccabe-nist235r.pdf

SATC

Rosenberg, L., Hammer, T., Shaw, J. (1998). Metriche e affidabilità del software (Proceedings of IEEE International Symposium on Software Reliability Engineering). Recuperato il 14 maggio 2011 dal sito Web di Penn State University: https://citeseerx.ist.psu.edu/pdf/31e3f5732a7af3aecd364b6cc2a85d9495b5c159