Quali metriche di codice ti convincono che il codice fornito è "scadente"? [chiuso]

https://stackoverflow.com/questions/187289

06-07-2019
|

Domanda

Linee di codice per file, metodi per classe, complessità ciclomatica e così via. Gli sviluppatori resistono e aggirano la maggior parte se non tutti! C'è un buon articolo di Joel su di esso (non c'è tempo per trovarlo ora ).

Quali metriche di codice si consiglia di utilizzare per automaticamente identificare " codice scadente " ;?

Cosa può convincere di più (non puoi convincere tutti noi a qualche metrica schifosa!: O)) degli sviluppatori che questo codice è "crap".

Conta solo le metriche che possono essere misurate automaticamente!

Soluzione

Nessuna metrica relativa allo stile di codifica fa parte di tale avviso.

Per me si tratta di analisi statica del codice , che può essere veramente "sempre" attivo:

complessità ciclomatica (rilevata da checkstyle)
rilevamento del ciclo di dipendenza (tramite findbugs per esempio)
errori critici rilevati da, ad esempio findbugs.

Vorrei mettere il test di copertura in un secondo passaggio, poiché tali test possono richiedere del tempo.

Non dimenticare che " schifoso " il codice non viene rilevato dalle metriche, ma dalla combinazione e evoluzione (come in " tendenza ) delle metriche: vedi Qual è il fascino delle metriche del codice? domanda.

Ciò significa che non devi solo raccomandare le metriche del codice per "identificare automaticamente" il codice scadente ", ma devi anche raccomandare la giusta combinazione e analisi delle tendenze per seguire tali metriche.

Condivido la tua frustration ;), e non condivido il punto di vista del tloach (nei commenti di altre risposte) " Fai una domanda vaga, ottieni una risposta vaga " dice ... la tua domanda merita una risposta specifica.

Altri suggerimenti

Non è una soluzione automatizzata, ma trovo utile WTF al minuto.

_{(fonte: osnews.com )}

Numero di avvisi che il compilatore emette quando eseguo una compilazione.

Numero di righe commentate per riga del codice di produzione. Generalmente indica un programmatore sciatto che non capisce il controllo della versione.

Gli sviluppatori si preoccupano sempre che le metriche vengano utilizzate contro di loro e che chiamino "schifoso" il codice non è un buon inizio. Questo è importante perché se sei preoccupato per i tuoi sviluppatori che giocano attorno a loro, allora non usare le metriche per tutto ciò che è a loro vantaggio / svantaggio.

Il modo in cui funziona meglio è non lasciare che la metrica ti dica dove il codice è scadente, ma usa la metrica per determinare dove devi cercare. Hai una revisione del codice e la decisione su come risolvere il problema è tra lo sviluppatore e il revisore. Vorrei anche errore dal lato dello sviluppatore contro la metrica. Se il codice continua a essere visualizzato sulla metrica ma i revisori pensano che sia buono, lascialo da solo.

Ma è importante tenere presente questo effetto di gioco quando le tue metriche iniziano a migliorare. Bene, ora ho una copertura del 100% ma i test unitari sono buoni? La metrica mi dice che sto bene, ma devo ancora verificarlo e vedere cosa ci ha portato lì.

In conclusione, l'essere umano batte la macchina.

numero di variabili globali.

Test inesistenti (rivelati dalla copertura del codice). Non è necessariamente un indicatore del cattivo codice, ma è un grande segnale di avvertimento.
Oscenità nei commenti.

Le metriche da sole non identificano il codice scadente. Tuttavia possono identificare codice sospetto.

Esistono molte metriche per il software OO. Alcuni di essi possono essere molto utili:

Dimensione media del metodo (sia in LOC / Dichiarazioni o complessità). Metodi di grandi dimensioni possono essere un segno di cattiva progettazione.
Numero di metodi sovrascritti da una sottoclasse. Un numero elevato indica un design di classe scadente.
Indice di specializzazione (numero di metodi sostituiti * livello di annidamento / numero totale di metodi). I numeri alti indicano possibili problemi nel diagramma di classe.

Esistono molte più metriche valide e possono essere calcolate utilizzando gli strumenti. Questo può essere un valido aiuto per identificare il codice scadente.

variabili globali
numeri magici
rapporto codice / commento
accoppiamento pesante (ad esempio, in C ++ è possibile misurarlo osservando le relazioni di classe o il numero di file cpp / header che si incrociano tra loro
const_cast o altri tipi di casting all'interno della stessa base di codice (non con librerie esterne)
grandi parti di codice commentate e lasciate lì

Il mio flag di avviso preferito personale: commenta il codice gratuito. Di solito significa che il programmatore non si è fermato a pensarci; inoltre rende automaticamente difficile la comprensione, quindi aumenta il rapporto scadente.

A prima vista: applicazione cult cult di idiomi di codice.

Non appena avrò un'occhiata più da vicino: ovvi bug e idee sbagliate da parte del programmatore.

La mia scommessa: combinazione di complessità ciclomatica (CC) e copertura del codice dai test automatici (TC).

CC | TC

 2 | 0%  - good anyway, cyclomatic complexity too small

10 | 70% - good

10 | 50% - could be better

10 | 20% - bad

20 | 85% - good

20 | 70% - could be better

20 | 50% - bad

...

crap4j - possibile strumento (per java) e spiegazione del concetto ... alla ricerca di uno strumento amichevole per C # : (

Numero di commenti inutili a commenti significativi:

'Set i to 1'
Dim i as Integer = 1

Non credo ci sia una tale metrica. Con l'eccezione del codice che in realtà non fa ciò che dovrebbe (che è un livello extra di merda) codice "merda" significa codice che è difficile da mantenere. Questo di solito significa che è difficile da capire per il manutentore, che è sempre in qualche modo soggettivo, proprio come una cattiva scrittura. Naturalmente ci sono casi in cui tutti concordano sul fatto che la scrittura (o il codice) sia scadente, ma è molto difficile scrivere una metrica per questo.

Inoltre, tutto è relativo. Il codice che svolge una funzione estremamente complessa, con una memoria minima, ottimizzata per ogni ultimo ciclo di velocità, avrà un aspetto molto negativo rispetto a una semplice funzione senza restrizioni. Ma non è schifoso - sta solo facendo quello che deve.

Sfortunatamente non esiste una metrica di cui sia a conoscenza. Qualcosa da tenere a mente non importa cosa tu scelga, i programmatori giocheranno al sistema per far apparire bene il loro codice. Ho visto che ovunque qualsiasi tipo di "automatico" la metrica è stata implementata.

Molte conversioni da e verso le stringhe. Generalmente è un segno che lo sviluppatore non è chiaro su cosa sta succedendo e sta semplicemente provando cose casuali fino a quando qualcosa non funziona. Ad esempio, ho visto spesso codice come questo:

   object num = GetABoxedInt();
//   long myLong = (long) num;   // throws exception
   long myLong = Int64.Parse(num.ToString());

quando quello che volevano veramente era:

   long myLong = (long)(int)num;

Sono sorpreso che nessuno abbia menzionato crap4j .

Fai attenzione al rapporto tra le classi Pattern e le classi standard. Un rapporto elevato indicherebbe Patternite
Controlla i numeri magici non definiti come costanti
Utilizzare un'utilità di corrispondenza dei modelli per rilevare codice potenzialmente duplicato

A volte, lo sai solo quando lo vedi. Ad esempio, stamattina ho visto:

void mdLicense::SetWindows(bool Option) {
  _windows = (Option ? true: false);
}

Dovevo solo chiedermi 'perché qualcuno dovrebbe mai fare questo?'.

La copertura del codice ha un certo valore, ma altrimenti tendo a fare maggiormente affidamento sulla profilazione del codice per dire se il codice è scadente.

Rapporto tra commenti che includono volgarità e commenti che non lo fanno.

Superiore = codice migliore.

Righe di commenti / Righe di codice

valore > 1 - > cattivo (troppi commenti)

valore < 0,1 - > cattivo (non abbastanza commenti)

Regola i valori numerici in base alla tua esperienza ;-)

Prendo un approccio a più livelli con il primo livello che è ragionevole leggibilità compensato solo dalla complessità del problema da risolvere. Se non riesce a superare il test di leggibilità, di solito considero il codice meno che buono.

TODO: commenti nel codice di produzione. Mostra semplicemente che lo sviluppatore non esegue le attività fino al completamento.

Metodi con 30 argomenti. Su un servizio web. Questo è tutto.

Bene, ci sono vari modi in cui potresti usare per sottolineare se un codice è o meno un buon codice. Di seguito sono alcuni di quelli:

Coesività: beh, il blocco di codice, sia di classe che di metodo, se viene trovato per servire funzionalità multiple, allora il codice può essere trovato con una coesione più bassa. Il codice più basso nella coesione può essere definito come basso nella riutilizzabilità. Questo può essere ulteriormente definito come codice inferiore nella manutenibilità.
1. Complessità del codice: si può usare la complessità ciclomatica di McCabe (n. di punti decisionali) per determinare la complessità del codice. La complessità del codice, essendo elevata, può essere utilizzata per rappresentare codice con minore usabilità (difficile da leggere e comprendere).
2. Documentazione: il codice con un numero di documenti insufficiente può anche essere attribuito a una bassa qualità del software dal punto di vista dell'usabilità del codice.

Consulta la pagina seguente per leggere checklist per la revisione del codice.

Questo esilarante post sul blog La metrica CRAP del codice potrebbe essere utile.

Autorizzato sotto: CC-BY-SA insieme a attribuzione

Non affiliato a StackOverflow