Range di complessità ciclomatica [chiuso]

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

Alcuni programmatori sono fedeli sostenitori di TDD e non scriveranno alcun codice senza prima scrivere un test di unità. Altri programmatori sono perfettamente in grado di creare programmi perfettamente buoni e privi di bug senza dover scrivere un singolo test. Il livello di complessità ciclomatica che ogni gruppo può tollerare quasi sicuramente cambierà sostanzialmente.

È una metrica soggettiva; valuta l'impostazione della tua soluzione di metrica del codice e adattala a un punto che ti senti a tuo agio con quello che ti dà risultati sensati.

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

1. Alcune tecniche di refactoring spostano la complessità da un punto a un altro (non da il tuo codice al framework o da una libreria esterna ben testata, ma da una posizione all'altra del codebase ). Aiuta a ridurre la complessità ciclomatica e aiuta a convincere il tuo capo (o chiunque ami le presentazioni con una grafica in costante aumento) a spendere il tuo tempo a fare qualcosa di eccezionale, ma il codice rimane grave come prima.

2. Al contrario, a volte, quando si refactoring un progetto applicando alcuni schemi di progettazione e programmazione, la complessità ciclomatica può peggiorare, mentre il codice refactored dovrebbe essere chiaro: gli sviluppatori conoscono modelli di programmazione (almeno sono ci si aspetta che li conosca), quindi semplifica il codice per loro, ma la complessità ciclomatica non tiene conto di ciò.

3. Alcune altre tecniche di non-refactoring non influenzano affatto la complessità ciclomatica, mentre diminuiscono drasticamente la complessità di un codice per gli sviluppatori. Esempi: aggiunta di commenti o documentazione rilevanti. "Modernizzare" il codice usando lo zucchero sintattico.

4. Ci sono semplicemente casi in cui la complessità ciclomatica è irrilevante. Mi piace l'esempio dato da whatsisname nel suo commento : alcune grandi dichiarazioni switch possono essere estremamente chiari e riscriverli in un modo OOPy non sarebbe molto utile (e complicherebbe la comprensione del codice da parte dei principianti). Allo stesso tempo, quelle dichiarazioni sono un disastro, dal punto di vista della complessità ciclomatica.

5. Come già detto in precedenza da Robert Harvey , dipende dal team stesso.

In pratica, ho visto codice sorgente che aveva una buona complessità ciclomatica, ma che era terribile. Allo stesso tempo, ho visto codice con elevata complessità ciclomatica, ma non ho avuto troppa pena a comprenderlo.

È solo che non esiste e non potrebbe esserci alcuno strumento che indicherebbe, in modo impeccabile, quanto buono o cattivo sia un dato pezzo di codice o quanto sia facile da mantenere . Dato che non puoi programmare un'applicazione che dirà che un dato dipinto è un capolavoro, e che un altro dovrebbe essere gettato via, perché non ha valore artistico.

Ci sono metriche che sono state modificate dal design (come LOC o il numero di commenti per file), e ci sono metriche che possono fornire alcuni suggerimenti grezzi (come il numero di bug o la complessità ciclomatica). In tutti i casi, questi sono solo suggerimenti e dovrebbero essere usati con cautela.