Il conteggio LOC dovrebbe includere test e commenti?

StackOverflow https://stackoverflow.com/questions/274575

  •  07-07-2019
  •  | 
  •  

Domanda

Mentre LOC (# righe di codice) è una misurazione problematica della complessità di un codice, è la più popolare e, se usata con molta attenzione, può fornire una stima approssimativa delle complessità almeno relative delle basi di codice (cioè se una programma è 10KLOC e un altro è 100KLOC, scritto nella stessa lingua, da squadre di circa la stessa competenza, il secondo programma è quasi sicuramente molto più complesso).

Quando conti le righe di codice, preferisci contare i commenti? E i test?

Ho visto vari approcci a questo. Strumenti come cloc e sloccount consentono di includere o escludere commenti. Altre persone considerano i commenti parte del codice e della sua complessità.

Lo stesso dilemma esiste per i test unitari, che a volte possono raggiungere la dimensione del codice testato stesso e persino superarlo.

Ho visto approcci in tutto lo spettro, contando solo "operativo" non commentare le righe non vuote, per "quotare XXX righe di codice testato e commentato", che è più come eseguire "quot-wc -l su tutti i file di codice nel progetto"

Qual è la tua preferenza personale e perché?

È stato utile?

Soluzione

Un uomo saggio una volta mi ha detto 'ottieni ciò che misuri' quando si tratta di gestire i programmatori.

Se li giudichi sorprendentemente nell'output LOC, tendi a ottenere molte righe di codice.

Se li valuti in base al numero di bug che chiudono, sorprendentemente ricevi molti bug corretti.

Se li valuti per le funzionalità aggiunte, otterrai molte funzionalità.

Se li valuti in base alla complessità ciclomatica otterrai funzioni ridicolmente semplici.

Dato che uno dei maggiori problemi con le basi di codice in questi giorni è la velocità con cui crescono e quanto sono difficili da cambiare una volta cresciuti, tendo a evitare di usare LOC come metrica, perché spinge il comportamento fondamentale errato.

Detto questo, se devi usarlo, conta senza commenti e test e richiede uno stile di codifica coerente.

Ma se vuoi davvero una misura di 'dimensione del codice' basta tar.gz la base di codice. Tende a servire come una migliore stima approssimativa del "contenuto" rispetto al conteggio delle righe che è sensibile ai diversi stili di programmazione.

Altri suggerimenti

Anche i test e i commenti devono essere mantenuti. Se intendi utilizzare LOC come metrica (e suppongo che non riesco a farti capire), dovresti fornire tutte e tre le righe (righe di codice reale, commenti, test).

La cosa più importante (e speriamo ovvia) è che tu sia coerente. Non segnalare un progetto con solo le righe del codice reale e un altro con tutte e tre le combinazioni. Trova o crea uno strumento che automatizzerà questo processo e genererà un rapporto. 

Lines of Code:       75,000
Lines of Comments:   10,000
Lines of Tests:      15,000
                  ---------
Total:              100,000

In questo modo puoi essere sicuro che lo farà

  1. Completa.
  2. Fatti allo stesso modo ogni volta.

Personalmente non ritengo che la metrica LOC da sola sia utile come alcune delle altre metriche del codice.

NDepend ti fornirà la metrica LOC ma ti darà anche molti altri, come la complessità ciclometrica. Anziché elencarli tutti, ecco il link all'elenco.

Esiste anche un componente aggiuntivo CodeMetric gratuito per Riflettore

Non risponderò direttamente alla tua domanda per un semplice motivo: odio le righe della metrica del codice. Non importa cosa stai cercando di misurare, è molto difficile fare di peggio di LOC; Praticamente qualsiasi altra metrica che ti interessa pensare sarà migliore.

In particolare, sembra che tu voglia misurare la complessità del tuo codice. La complessità ciclometrica (anche chiamata complessità di McCabe) è una metrica molto migliore per questo.

Le routine con un'elevata complessità ciclometrica sono le routine su cui vuoi focalizzare la tua attenzione. Sono queste routine che sono difficili da testare, marce fino al midollo con bug e difficili da mantenere.

Esistono molti strumenti che misurano questo tipo di complessità. Una rapida ricerca su Google nella tua lingua preferita troverà dozzine di strumenti che rendono questo tipo di complessità.

Linee di codice significa esattamente che: non vengono conteggiati commenti o righe vuote. E affinché sia ??paragonabile ad altri codici sorgente (indipendentemente dal fatto che la metrica sia utile o meno), è necessario almeno stili di codifica simili: 

for (int i = 0; i < list.count; i++)
{
    // do some stuff
}

for (int i = 0; i < list.count; i++){
    // do some stuff
}

La seconda versione fa esattamente lo stesso, ma ha un LOC in meno. Quando hai molti loop nidificati, questo può riassumere un po '. Ecco perché sono state inventate metriche come punti funzione .

Dipende da cosa stai usando LOC per.

Come misura di complessità - non tanto. Forse i 100KLOC sono principalmente codice generato da una semplice tabella, e il 10KLOC è regexps 5KLOC.

Tuttavia, vedo ogni riga di codice associata a un costo di gestione. Paghi per ogni riga per tutta la durata del programma: deve essere letto quando mantenuto, potrebbe contenere un errore che deve essere riparato, aumenta i tempi di compilazione, il controllo del codice sorgente e i tempi di backup, prima di cambiare o rimuoverlo potrebbe essere necessario scoprire se qualcuno fa affidamento su di esso, ecc. Il costo medio può essere di nanopennies per riga e giorno, ma è roba che si somma.

KLOC può essere un primo indicatore di quanta infrastruttura necessita un progetto. In tal caso, includerei commenti e test, anche se il costo di esecuzione di una riga di commento è molto inferiore a uno dei regexp del secondo progetto.

[modifica] [qualcuno con un'opinione simile sulla dimensione del codice] 1

Utilizziamo solo una riga di metrica per una cosa: una funzione dovrebbe contenere poche righe di codice sufficienti per essere letta senza scorrere lo schermo. Le funzioni più grandi di quelle di solito sono difficili da leggere, anche se hanno una complessità ciclometrica molto bassa. Per il suo uso contiamo spazi bianchi e commenti.

Può anche essere bello vedere quante righe di codice hai rimosso durante un refactor - qui vuoi solo contare le righe di codice effettive, spazi bianchi che non aiutano la leggibilità e i commenti che non sono utili (che non possono essere automatizzati).

Finalmente un disclaimer: usa le metriche in modo intelligente. Un buon uso delle metriche è di aiutare a rispondere alla domanda "quale parte del codice trarrebbe maggior beneficio dal refactoring" o "quanto è urgente una revisione del codice per l'ultimo check-in?" - una funzione da 1000 linee con una complessità ciclomatica di 50 è un'insegna al neon lampeggiante che dice "refactor me now". Un cattivo uso delle metriche è "quanto è produttivo il programmatore X" o "Quanto è complicato il mio software" .

Estratto dall'articolo: Come conteggi il tuo numero di righe di codice (LOC)? rispetto allo strumento NDepend che conta la logica numero di righe di codice per i programmi .NET.

Come conteggi il tuo numero di righe di codice (LOC)?

Conti la dichiarazione della firma del metodo? Conta le righe con solo parentesi? Contate più righe quando una singola chiamata di metodo viene scritta su più righe a causa di un numero elevato di parametri? Conti & # 8216; namespace & # 8217; e & # 8216; utilizzando lo spazio dei nomi & # 8217; dichiarazione? Conti la dichiarazione dell'interfaccia e dei metodi astratti? Conti l'assegnazione dei campi quando vengono dichiarati? Conti una riga vuota?

A seconda dello stile di codifica di ciascuno sviluppatore e in base alla lingua scelta (C #, VB.NET & # 8230;) può esserci una differenza significativa misurando il LOC.

Apparentemente la misurazione del LOC dall'analisi dei file sorgente sembra un argomento complesso. Grazie a un astuto esiste un modo semplice per misurare esattamente ciò che viene chiamato LOC logico. Il LOC logico presenta 2 vantaggi significativi rispetto al LOC fisico (il LOC che viene dedotto dall'analisi dei file di origine):

  • Lo stile di codifica non interferisce con la LOC logica. Ad esempio, il LOC non cambierà perché una chiamata al metodo viene generata su più righe a causa di un elevato numero di argomenti.
  • La LOC logica è indipendente dalla lingua. I valori ottenuti da assiemi scritti con lingue diverse sono comparabili e possono essere sommati.

Nel mondo .NET, la LOC logica può essere calcolata dai file PDB, i file utilizzati dal debugger per collegare il codice IL con il codice sorgente. Lo strumento NDepend calcola il LOC logico per un metodo in questo modo: è uguale al numero di punti di sequenza trovati per un metodo nel file PDB. Un punto di sequenza viene utilizzato per contrassegnare un punto nel codice IL che corrisponde a una posizione specifica nella fonte originale. Maggiori informazioni sui punti di sequenza qui. Nota che i punti di sequenza che corrispondono alle parentesi graffe C # & # 8216; {& # 8216; e & # 8216;} & # 8217; non sono presi in considerazione.

Ovviamente, il LOC per un tipo è la somma dei suoi metodi & # 8217; LOC, il LOC per uno spazio dei nomi è la somma dei suoi tipi & # 8217; LOC, il LOC per un assembly è la somma dei suoi spazi dei nomi & # 8217; LOC e LOC per un'applicazione è la somma dei suoi assembly LOC. Ecco alcune osservazioni:

  • Le interfacce, i metodi astratti e le enumerazioni hanno un LOC uguale a 0. Durante il calcolo del LOC viene considerato solo il codice concreto che viene effettivamente eseguito.
  • Le dichiarazioni di spazi dei nomi, tipi, campi e metodi non sono considerate come riga di codice perché non hanno punti di sequenza corrispondenti.
  • Quando il compilatore C # o VB.NET deve affrontare un'inizializzazione di campi di istanza inline, genera un punto sequenza per ciascuno dei costruttori di istanze (la stessa osservazione vale per l'inizializzazione di campi statici inline e il costruttore statico).
  • LOC calcolato da un metodo anonimo non interferisce con il LOC dei suoi metodi di dichiarazione esterni.
  • Il rapporto complessivo tra NbILInstructions e LOC (in C # e VB.NET) è di solito intorno a 7.
Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top