La densità della complessità ciclomatica è una metrica di buona qualità del software? [duplicare]

Question

La densità della complessità ciclomatica è una metrica di buona qualità del software? [duplicare]

#1 da (6 voti)
#2 da (6 voti)

3

Dove definisco la densità della complessità ciclomatica come:

Cyclomatic complexity density = Cyclomatic complexity / Lines of code

Leggevo discussioni precedenti sulla complessità ciclomatica e sembra esserci una sorta di consenso sul fatto che abbia mescolato l'utilità, e come tale probabilmente non c'è un strong motivo per usarlo su una semplice metrica di codice (LOC) . Cioè Poiché le dimensioni di una classe o di un metodo aumentano oltre una certa soglia, la probabilità di difetti e di quelle che sono state scelte di design scadenti aumenta.

Mi sembra che la complessità ciclomatica (CC) e LOC tenderanno ad essere correlate, quindi l'argomento per l'uso della metrica LOC più semplice. Tuttavia, potrebbero esserci casi anomali in cui la complessità è più elevata in alcune regioni del codice, cioè c'è una maggiore densità di rami di esecuzione in alcuni pezzi (rispetto alla media) e mi chiedo se questo tenderà ad essere correlato con il presenza di difetti.

Esistono prove a favore o contro, o ci sono esperienze sull'uso di una tale metrica di densità di complessità?

O forse una metrica migliore è avere sia una soglia LOC sia una soglia CC, e consideriamo il superamento della soglia come negativa.

code-quality quality cyclomatic-complexity

posta redcalx 22.07.2015 - 00:37

fonte

2 risposte

Leggi altre domande sui tag code-quality quality cyclomatic-complexity

L'accesso ai membri di livello inferiore di un aggregato per eseguire una cattiva pratica di un'operazione? Perché Python 3.4 è ancora sviluppato dopo il rilascio di 3.5? [chiuso]

score 6 · Answer 1

Considera quanto segue:

define dispatch_message (message_id, message_contents)
    if (message_id == MESSAGE_ID_1)
        FirstMessageId(message_contents).dispatch()
    else if (message_id == MESSAGE_ID_2)
        SecondMessageId(message_contents).dispatch()
    ...
    else if (message_id == MESSAGE_ID_N)
        NthMessageId(message_contents).dispatch()
    else
        raise_or_throw_an_error
    end if
end function

Questa funzione comprende 2N + 5 linee di codice e ha una complessità ciclomatica di N + 1 o N + 3, a seconda di come si conta raise_or_throw_an_error . Supponiamo che N sia 200. La densità di complessità è intorno a 1/2. Cosa significa? D'altra parte, una funzione che ha un conteggio delle righe di 4005 e una complessità di oltre 2000 significa qualcosa.

Nonostante abbia una complessità di 2000+, la mia funzione non è completamente terribile. (Va bene, è terribile, ci sono modi più moderni per farlo.) Questo è sorprendentemente un costrutto abbastanza comune in sistemi ad altissima affidabilità. Fatto bene, è abbastanza ovvio ciò che sta facendo la funzione.

Un problema con la divisione di SLOC per complessità è che esiste una strong correlazione tra gli SLOC e la complessità. La mia funzione è un'anomalia. Tutto ciò che la tua metrica mostrerà è che la mia funzione è anomala. All'altro estremo, considera una funzione autogenerata molto lunga con una complessità ciclomatica di uno. Anche questi non sono così problematici da soli. (È il generatore che devi controllare, non la funzione lunga linea 40000.)

I due estremi dello SLOC al rapporto di complessità non sono i posti dove cercare i bachi. È da qualche parte nel mezzo. Sfortunatamente, è lì che troverai la maggior parte delle tue funzioni. SLOC e complessità danno falsi allarmi, ma vale la pena indagare su questi falsi allarmi. Non vedo la stessa applicazione alla metrica del rapporto di complessità SLOC. Molto probabilmente le funzioni più difficili saranno nascoste tra un numero enorme di funzioni non allarmanti con un rapporto SLOC simile a quello della complessità.

score 6 · Answer 2

Non ci sono metriche sulla qualità del software che siano buone - almeno nessuna è ancora conosciuta. Anni di ricerche non ci hanno ancora fornito di buono.

Quindi la risposta se una delle metriche suggerite è una buona metrica per la qualità del software è un "no" deludente.

Ci sono alcune metriche che sono indicatori ragionevoli di software non valido. Ma la mancanza di segni di cattivo software non rende il software buono. Inoltre, quegli indicatori sono molto pignoli, con molte eccezioni, quindi il rifiuto automatico del codice errato non è pratico nella pratica.

I ricercatori discutono queste metriche e mettono in correlazione le metriche con i bug, ma di solito quelle correlazioni non sono più forti di "programmi più grandi contengono più bug". Come questa voce su Wikipedia ammette:

The essence of this observation is that larger programs (more complex programs as defined by McCabe's metric) tend to have more defects. Although this relation is probably true, it isn't commercially useful.

Di conseguenza, queste metriche sono usate a malapena nel mondo commerciale - non risparmiano né tempo né denaro.

Questo non dovrebbe impedire ai ricercatori di cercarne di migliori. Ma finora, a mio avviso, si tratta di un esercizio teorico con quasi nessun utilizzo pratico.

Durante i miei 20 anni di lavoro nell'ICT commerciale, ho riscontrato due parametri utilizzati nella pratica e nessuno dei due può essere automatizzato:

"Numero di clienti paganti soddisfatti", noto anche come "Quanto ci guadagna?"
"WTF al minuto" quando i peer leggono il tuo codice.

Ecco perché questa immagine è popolare - l'ho vista in più negozi: