Intervalli di complessità ciclomatica [chiuso]

Chiuso . Questa domanda è basata sull'opinione . Al momento non accetta risposte.

Vuoi migliorare questa domanda? Aggiorna la domanda in modo che possa essere risolta con fatti e citazioni modificando questo post .

Chiuso 5 anni fa .

Quali sono le categorie di complessità ciclomatica? Per esempio:

1-5: facile da mantenere
6-10: difficile
11-15: molto difficile
20+: avvicinamento impossibile

Per anni ormai, ho assunto il presupposto che il limite fosse 10. E qualsiasi cosa oltre a ciò è male. Sto analizzando una soluzione e sto cercando di determinare la qualità del codice. Certamente la complessità ciclomatica non è l'unica misura, ma può aiutare. Esistono metodi con una complessità ciclomatica di oltre 200. So che è terribile, ma sono curioso di conoscere le gamme inferiori, come nel mio esempio sopra.

Ho trovato questo :

I suddetti valori di riferimento di Carnegie Mellon definiscono quattro intervalli approssimativi per i valori di complessità ciclomatica:

i metodi tra 1 e 10 sono considerati semplici e di facile comprensione

valori compresi tra 10 e 20 indicano un codice più complesso, che può essere ancora comprensibile; tuttavia i test diventano più difficili a causa del maggior numero di possibili rami che il codice può accettare

i valori di 20 e superiori sono tipici del codice con un numero molto elevato di potenziali percorsi di esecuzione e possono essere colti e testati solo con grande difficoltà e fatica

i metodi che vanno ancora più in alto, ad es.> 50, sono certamente irraggiungibili

Quando si eseguono metriche di codice per una soluzione, i risultati mostrano il verde per qualsiasi valore inferiore a 25. Non sono d'accordo con questo, ma speravo di ottenere altri input.

Esiste un elenco di range generalmente accettato per la complessità ciclomatica?

design programming-practices metrics

— Bob Horn
fonte

Hai trovato dati dal Software Engineering Institute, un'organizzazione riconosciuta come leader nell'ingegneria del software. Non capisco quale sia la tua domanda: hai trovato un elenco di intervalli per la complessità ciclomatica. Cos'altro stai cercando?

— Thomas Owens

Ho visto varie gamme; quello era solo un esempio. E MS mostra "verde" per qualsiasi cosa sotto i 25 anni. Mi chiedevo se ci fosse un elenco di range accettato. Forse l'ho trovato allora.

— Bob Horn,

Sono d'accordo con @ThomasOwens, ma sono felice che tu abbia posto questa domanda. L'ho votato sia come domanda che come risposta.

— Evorlor,

Nella 2a edizione di Code Complete di Steve McConnell, egli raccomanda che una complessità ciclomatica da 0 a 5 sia in genere corretta, ma è necessario essere consapevoli se la complessità inizia a essere compresa tra 6 e 10. Spiega inoltre che qualsiasi cosa oltre una complessità di 10 dovresti prendere in seria considerazione il refactoring del tuo codice.

— GibboK,

Risposte:

Suppongo che dipenda dalle capacità del tuo personale di programmazione e, in minima parte, dalla tua sensibilità come manager.

Alcuni programmatori sono convinti sostenitori di TDD e non scriveranno alcun codice senza prima scrivere un test unitario. Altri programmatori sono perfettamente in grado di creare programmi perfettamente validi e senza bug senza scrivere un singolo test unitario. Il livello di complessità ciclomatica che ogni gruppo può tollerare varierà quasi sicuramente sostanzialmente.

È una metrica soggettiva; valuta l'impostazione sulla tua soluzione di metriche del codice e adattala a un punto ottimale con cui ti senti a tuo agio che ti dia risultati sensati.

— Robert Harvey
fonte

D'accordo, inoltre dipende da quale sia la causa della complessità. Una grande istruzione switch che chiama altre funzioni, come parte di una macchina a stati o qualcosa di simile, può avere una complessità molto elevata, nonostante sia forse praticamente banale da capire.

— whatsisname

Le affermazioni sui grandi switch non sono in genere un'indicazione di una mancanza di principi OOP, come il polimorfismo? Le macchine a stati possono essere implementate in modo elegante, con OOP o modelli di progettazione. No?

— Bob Horn,

Per alcuni problemi quell'eleganza è utile, per altri rende le cose più confuse. Non esiste un proiettile d'argento.

— whatsisname

-1 Per "Altri programmatori sono perfettamente in grado di creare programmi perfettamente validi e senza errori senza scrivere un singolo test unitario". Non puoi conoscerne i bug gratuitamente se non l'hai testato.

— Sebastien,

@Sebastien: l'assenza di test unitari non significa che non sia stato testato. E sì, se sei abbastanza bravo, è assolutamente possibile scrivere un codice privo di bug senza test o test di fumo rudimentale. Certo, quelle persone sono una razza rara.

— Robert Harvey,

Non ci sono categorie predefinite e nessuna categorizzazione sarebbe possibile per diversi motivi:

Alcune tecniche di refactoring basta spostare la complessità da un punto ad un altro (non dal vostro codice al quadro o una libreria esterna ben collaudato, ma da un luogo all'altro del codice di base). Aiuta a ridurre la complessità ciclomatica e aiuta a convincere il tuo capo (o chiunque ami le presentazioni con una grafica in costante aumento) che hai speso il tuo tempo a fare qualcosa di eccezionale, ma il codice rimane cattivo come in precedenza.
Al contrario, a volte, quando si esegue il refactoring di un progetto applicando alcuni schemi di progettazione e programmazione, la complessità ciclomatica può peggiorare, mentre il codice refactored dovrebbe essere chiaro: gli sviluppatori conoscono gli schemi di programmazione (almeno ci si aspetta che li conoscano), quindi semplifica il codice per loro, ma la complessità ciclomatica non ne tiene conto.
Alcune altre tecniche non di refactoring non influiscono affatto sulla complessità ciclomatica, mentre diminuiscono notevolmente la complessità di un codice per gli sviluppatori. Esempi: aggiunta di commenti o documentazione pertinenti. "Modernizzare" il codice usando lo zucchero sintattico.
Ci sono semplicemente casi in cui la complessità ciclomatica è irrilevante. Mi piace l'esempio dato da whatsisname nel suo commento : alcune switchaffermazioni di grandi dimensioni possono essere estremamente chiare e riscriverle in un modo più OOPy non sarebbe molto utile (e complicherebbe la comprensione del codice da parte dei principianti). Allo stesso tempo, queste affermazioni sono un disastro, dal punto di vista ciclistico della complessità.
Come Robert Harvey ha già detto sopra , dipende dalla squadra stessa.

In pratica, ho visto il codice sorgente che aveva una buona complessità ciclomatica, ma che era terribile. Allo stesso tempo, ho visto un codice con un'elevata complessità ciclomatica, ma non ho avuto molto dolore a capirlo.

È solo che non esiste e non potrebbe esserci uno strumento che indichi, in modo impeccabile, quanto sia buono o cattivo un dato codice o quanto sia facile da mantenere . Poiché non è possibile programmare un'applicazione che indichi che un determinato dipinto è un capolavoro e che un altro deve essere gettato via, perché non ha valore artistico.

Ci sono metriche che sono interrotte in base alla progettazione (come LOC o il numero di commenti per file) e ci sono metriche che possono dare alcuni suggerimenti grezzi (come il numero di bug o la complessità ciclomatica). In tutti i casi, questi sono solo suggerimenti e devono essere usati con cautela.

— Arseni Mourzenko
fonte

+1 Sono d'accordo con tutto quanto detto. La complessità ciclica o LOC sono solo metriche che ti vengono fornite dall'analisi del codice statico. Gli analizzatori statici sono ottimi strumenti, ma mancano di buon senso. Queste metriche devono essere elaborate da un cervello umano, preferibilmente uno appartenente a un programmatore esperto. Solo allora puoi dire se un particolare software è inutilmente complesso.