Quanto è importante ridurre il numero di righe nel codice?

Sono uno sviluppatore di software che lavora su J2SE (core java).
Spesso durante le nostre revisioni del codice ci viene chiesto di ridurre il numero di righe nel nostro codice.

Non si tratta di rimuovere il codice ridondante, si tratta di seguire uno stile che si concentra sul fare le stesse cose con meno righe nel codice, mentre io credo di avere chiarezza nel codice anche se ciò significa aumentare il numero di righe.

Quale pensi sia il modo giusto di fare le cose?
Se LOC (righe di codice) è un numero piccolo, come influisce sul codice? Se LOC è un numero maggiore, in che modo influisce sul codice?

esempio dal sito Web: "javaranch" -

public static void happyBirthday(int age)
{  
    if ((age == 16) || (age == 21) || ((age > 21) && (((age % 10) == 0) || ((age % 25) == 0))))        
    {
        System.out.println("Super special party, this year!");
    }
    else
    {
        System.out.println("One year older. Again.");
    }
}

VS

public static void happyBirthday(int age)
{

    boolean sweet_sixteen = (age == 16);
    boolean majority = (age == 21);
    boolean adult = (age > 21);
    boolean decade = (age % 10) == 0;
    boolean quarter = (age % 25) == 0;

    if (sweet_sixteen || majority || (adult && (decade || quarter)))
    {
        System.out.println("Super special party, this year!");
    }
    else
    {
        System.out.println("One year older. Again.");
    }
}

Il problema con le misurazioni, non importa quanto siano ben intenzionate, è l'atto stesso di misurare l'oggetto che lo rende importante, e il corollario, l'atto di non misurare un oggetto lo rende poco importante. È assolutamente essenziale misurare ciò che è importante e non misurare ciò che non è importante.

Misurare SLOC (che è effettivamente ciò che stanno facendo le tue recensioni), rende SLOC importante ... È importante SLOC? - assolutamente no, mai stato ( contest di programmazione esterna offuscata ), non sarà mai in un'organizzazione commerciale.

Ponetevi una semplice domanda: in che modo "Ridurre lo SLOC di questa routine" migliora il codice di chiunque. Ciò che sta probabilmente accadendo in questo caso è che SLOC viene utilizzato come un modo ingenuo per misurare la complessità. Quello che devi evitare a tutti i costi è contare i fagioli facili da contare - misure oggettive come SLOC, invece di contare quelli importanti, ma difficili da contare - ad es. Leggibilità, complessità ecc.

Sono d'accordo con i tuoi revisori del codice, ma con un asterisco. Ogni affermazione che scrivi nel tuo codice è una responsabilità tecnica - è un potenziale punto di errore. Se scrivi un metodo con 10 istruzioni e il tuo collega ne scrive uno che raggiunge la stessa funzionalità con 5 istruzioni, è probabile che il suo sia "migliore" misurato dalla probabilità di problemi (ci sono due volte più punti in cui il tuo codice può essere sbagliato, eccessivamente complesso o problematico).

Ecco l'asterisco, però. Non si tratta del numero effettivo di righe di codice nell'idea perché è possibile ridurre il numero di righe con qualcosa del tipo:

void someMethod() {   
 someobject.doSomething(someSingleton.getInstance().with().a().lot().of().law().of().demeter().violations()).and().if().that().werent().enough().theres().more();
}

Questa è una riga di codice, ma è un luogo in cui una quantità incredibile di cose può andare storto. Quindi direi che concentrati sul fare di più con il minor numero di istruzioni: scrivi tutto il codice di cui hai bisogno per fare le cose e non di più. Almeno, penso che sia quello a cui stanno guidando i tuoi revisori del codice.

Personalmente, penso che ci sia un equilibrio da raggiungere. Come ho detto, ogni affermazione che scrivi è una responsabilità, ma se estrarre una variabile locale con un nome descrittivo rende il tuo metodo molto più chiaro e più leggibile, allora c'è un caso da fare anche per quello. Penso che tu possa facilmente entrare in situazioni in cui le persone stanno cavillando su differenze estetiche relativamente minori, ma nel complesso, penso che i tuoi revisori abbiano l'idea giusta: favorire la riduzione al minimo del numero di cose che possono andare storte.

Seguire letteralmente i consigli dei revisori non farà nulla di buono, perché l'ovvio risultato diretto sta promuovendo una linea sottile (nonostante il limite di lunghezza della linea). Credo che la lezione da imparare qui, tuttavia, sia quella di fare in modo che il tuo codice faccia meno cose .

In altre parole, questa è una richiesta di semplicità. È abbastanza popolare affermare che il codice sia una responsabilità, non un bene , quindi ridurne l'importo pur preservando la funzionalità è uno sforzo nobile. Ciò può essere ottenuto con un approccio diretto e più diretto che affronta direttamente il problema e preferisce soluzioni concise.

Come disse una volta Ken Thompson: Uno dei miei giorni più produttivi è stato quello di buttare via 1000 righe di codice .

Tendo a concordare con la tua posizione di "avere chiarezza nel codice anche se ciò significa aumentare il numero di righe".

Ho visto troppi liner che sono abbastanza concisi, ma non è immediatamente chiaro cosa stiano facendo. La leggibilità è fondamentale poiché altri sviluppatori dovranno mantenere il tuo codice.

Direi che una cosa migliore a cui puntare sono i metodi brevi. Non abbreviato per amore di poche righe di codice, ma abbreviato perché fanno una sola cosa.

Attualmente lavoro come sviluppatore di applicazioni senior e analista di business di progetto per una grande azienda e il numero di linee del mio sviluppo non è mai stato un centro di interesse. Tuttavia, credo che più un codice può essere condensato, meglio è, MA non a costo di essere in grado di analizzarlo e correggerlo (o aggiungerlo) rapidamente. Per me, quando sei responsabile di applicazioni business-critical che DEVONO avere un vasto livello di scalabilità e in grado di alterazioni al volo in un ambiente in continua evoluzione, il codice conciso e di facile lettura è uno degli elementi più importanti nello sviluppo . A merito della risposta di Erik Dietrich , questo:

void someMethod() {   
someobject.doSomething(someSingleton.getInstance().with().a().lot().of().law().of().demeter().violations()).and().if().that().werent().enough().theres().more();
}

sarebbe del tutto inaccettabile per me, tuttavia, ho scoperto che alterava tutto il codice esistente delle società da:

if (boolean == true){
value.prop = option1;
}
else{
value.prop = option2;
}

per:

value.prop =  boolean ? option1 : option2;

è stata un'ottima scelta di condensazione del codice che non sacrifica la leggibilità.

Per quanto riguarda l'effetto del codice? Non ho mai notato un aumento o una riduzione delle prestazioni da, diciamo, 100 righe di codice. Il fatto è che è più il processo che si utilizza per arrivare al prodotto finale che il numero di linee che ci vuole per arrivare lì. Ho visto alcuni processi scritti molto condensati, per quanto inefficienti, che funzionano diversamente dai codici più lunghi con un flusso di codice migliore.

IMO, è una cattiva idea misurare l'efficacia del codice con un banale conteggio LOC. C'è molto di più in ciò che rende il codice correttamente progettato ed efficace.

Nella mia esperienza, codice efficace:

• non infrange nessuno dei principi SOLIDI
• è leggibile e si spiega da sé
• supera la prova di semplicità di Albert Einstein: "Tutto dovrebbe essere reso il più semplice possibile, ma non più semplice".

Ci sono molte risposte qui che affrontano i pro e i contro tecnici di mantenere LOC basso e se si tratta di una metrica software di qualità significativa. Non è questa la domanda. Di cosa si tratta è come gestire la gestione che insiste su un'ingenua aderenza dogmatica a una particolare regola empirica di codifica.

Purtroppo, è abbastanza comune per le persone aggrapparsi a cose che sono buoni consigli se usate nel giusto contesto e applicate pragmaticamente, portarle fuori da quel contesto e applicarle dogmaticamente senza riuscire ad apprezzare i problemi che i consigli esistono per mitigare in primo luogo .

L'intento di un consiglio riguardo a mantenere il LOC basso è quello di evitare la creazione di metodi che provano a fare troppo in una volta sola e di scoraggiare la creazione di "classi divine", che conoscono troppo gli aspetti di un progetto che non sono loro responsabilità diretta e da cui dipendono tutte le altre classi del sistema. Un altro vantaggio del codice più breve è che è più leggibile, anche se come hai sottolineato, puoi esagerare al punto in cui la leggibilità inizia effettivamente a soffrire.

Ci sono evidenti vantaggi in termini di LOC bassi (i metodi più piccoli si adattano alla tua testa più facilmente di quelli grandi, meno cose nel codice significano meno cose che vanno male, ecc.), Ma sono anche soggette alla legge dei rendimenti decrescenti. Rifattorizzare un metodo a 150 linee in un numero di metodi a 20 linee è una vittoria molto maggiore rispetto al rifattorizzare un metodo a 10 linee in un metodo a 7 linee.

Quando tale refactoring viene a scapito di qualche altro aspetto del buon design del software (come la leggibilità), hai raggiunto un punto in cui puoi giustificare di non farlo. Rimuovere variabili che danno contesto al significato del codice e sostituirle con valori letterali che non lo fanno è una cosa molto brutta da fare. Il buon codice non contiene quasi letterali. Tuttavia, queste variabili (e le costanti nominate) sono linee di codice che non contribuiscono direttamente al programma e quindi se LOC viene venerato come una sorta di dio, tali linee di chiarimento sono in grande pericolo di essere potate per una rapida vittoria e qualche elogio fuorviato dalla direzione.

Credo che tu sia abbastanza intelligente per rendertene conto, in effetti è praticamente la spinta della tua domanda originale. Il problema non è la tua comprensione di quando la riduzione del codice è buona e quando non lo è, il problema è il dogmatismo nell'applicare indiscriminatamente quella che normalmente è una pratica ragionevole.

Consiglierei di prenderti il ​​tempo di chattare con la tua direzione, spiegando la tua posizione e perché ritieni che ciò che ti viene chiesto di danneggiare il codice piuttosto che aiutarlo. Cerca di evitare di essere conflittuale, ma cerca di rimanere razionale e calmo durante una simile discussione. È importante che la direzione capisca che la programmazione è un'attività pragmatica e che i consigli sulle migliori pratiche sono utili solo se applicati in modo pragmatico. La migliore pratica è scritta in un libro, non scolpito nella pietra, e quando è in conflitto (codice breve contro codice leggibile) spetta al programmatore applicare il proprio giudizio su quale migliore pratica seguire. Speriamo che siano persone ragionevoli che apprezzano input come questo.

Devi anche essere un po 'coraggioso, perché se sei sotto pressione per ridurre LOC dove pensi che non sia necessario o inappropriato, è naturale che tu faccia il cambiamento comunque per il bene di una vita tranquilla. Devi resistere nel fare questo, e devi "possedere" quella decisione. In una situazione in cui la gestione è ragionevole, non dovresti rispettare esattamente le loro linee guida, ma dovresti essere in grado di giustificare qualsiasi circostanza in cui non lo fai.

Purtroppo, le persone possono essere irrazionali, soprattutto quando si tratta di persone inferiori sull'ordine di beccare in discussione le loro decisioni e le regole che ti hanno imposto. Potrebbero scegliere di non essere ragionevoli. Devi essere preparato anche per quello. Se riesci a dimostrare casi in cui le migliori pratiche LOC entrano in conflitto diretto con altre migliori pratiche e perché ciò danneggia il prodotto, e se puoi farlo in porzioni della base di codice per le quali hanno avuto un coinvolgimento personale scarso o nullo (quindi non sembra un attacco personale al loro lavoro o al lavoro che hanno supervisionato), quindi questo può aiutare a sostenere la tua discussione. Ancora una volta, devi essere preparato a giustificarti in un modo calmo e razionale ed essere in grado di "possedere" gli argomenti che stai facendo.

A condizione che la tua gestione sia composta da persone ragionevoli, allora devono apprezzare che ciò che stai dicendo ha valore se puoi fornire prove a sostegno delle tue affermazioni.

Penso che dovresti davvero cercare di avere funzioni con un numero limitato di SLOC.

Se LOC (righe di codice) è un numero piccolo, come influisce sul codice e se LOC è un numero più grande, come influisce sul codice?

Idealmente, dovrebbe essere più semplice capire 8 righe di codice a colpo d'occhio di quanto dovrebbe essere capire 30.

Ciò non significa che 30 LOC compressi in 8 righe saranno più facili da capire.

Quale pensi sia il modo giusto di fare le cose.

Normalmente in una funzione, provo a raggrupparlo per livelli di astrazione ("codice IO qui", "convalida qui", "calcolo qui" e così via).

Quindi, l'ho diviso in blocchi, separati da una linea vuota. Se il codice è più di una decina di righe, estraggo ogni blocco in una funzione diversa (lo faccio comunque per il codice che appare più di una volta). Ho sentito una discussione sulla rottura delle prestazioni in questo modo (chiamate di funzione non necessarie) ma in pratica non ho mai avuto un collo di bottiglia nelle prestazioni causato da questo.

Detto questo, ho svolto funzioni con questa estrazione, e dopo di ciò la funzione era lunga ~ 40 righe (codice C). Se il codice è il più raggruppato possibile, non vedo problemi con funzioni più lunghe.

Penso che sia più importante concentrarsi su codice pulito e auto-documentato, rispetto a LOC. Non mi piace molto il tuo esempio, però, perché spiega cosa sta facendo il codice, senza dire perché. Ad esempio, questo:

booleano sweet_sixteen = (età == 16);

è piuttosto ridondante. Chiunque legga "age == 16" lo sa. Preferirei scrivere il codice in questo modo:

public static boolean companyShouldThrowABigParty(int age) {
    return (age == 16) || (age == 21) || ((age > 21) && (((age % 10) == 0) || ((age % 25) == 0))); 
}

public static void happyBirthday(int age)
{  
    System.out.println(companyShouldThrowABigParty(age) ? "Super special party, this year!" : "One year older. Again.");
}

La logica di decidere quando organizzare la festa è separata da System.out, può essere testata ed è facile da capire. Ancora più importante, però, qualcuno che legge il codice può capire il motivo per cui è stato scritto in quel modo ("la compagnia vuole organizzare una grande festa per alcune persone").

Penso che meno righe di codice = codice più leggibile

Ma, naturalmente, c'è qualche limite, quando inizi a minimizzare / oscurare il tuo codice solo per ottenere meno righe.

/** Pad a number with 0 on the left */
function zeroPad(number, digits) {
    var num = number+"";
    while(num.length < digits){
        num='0'+num;
    }
    return num;
}

Questa è la minimizzazione, la logica rimane la stessa, solo meno leggibile. Questo non dovrebbe essere fatto dagli umani, questa minificazione è fatta dalla macchina per essere letta da una macchina.

function zP(e,t){var n=e+"";while(n.length<t){n="0"+n}return n}

Se riesci a rimuovere un pezzo di codice e l'algoritmo continua a fare ciò che dovrebbe fare, ok vai avanti. Basta non minimizzare il tuo codice, ci sono strumenti migliori per farlo.

Non credo che meno righe di codice == codice più leggibile. Tuttavia, la realtà, che è molto diversa dalla teoria, è che il codice con un gran numero di righe è spesso scritto senza un disegno adeguato. Di conseguenza, il requisito di un minor numero di righe PU force forzare alcuni programmatori a progettare meglio se sono in grado. La svolta è che molti programmatori non lo sono, quindi il requisito non aiuta molto.

Non vedrei il numero di righe come un problema in circostanze normali, ma può indicare problemi. Se qualcuno ti mostra una classe con 1000 righe di codice, allora qualcosa deve essere sbagliato nel modo in cui la classe è stata creata o progettata.

Il tuo esempio indica un caso in cui ha senso un numero maggiore di righe di codice. Ma questo è questo esempio. Ogni giorno vedo esempi in cui il numero di righe è collegato alla mancanza di pianificazione

LOC è una metrica molto più utile all'inizio di un progetto che durante l'implementazione effettiva, credo. Conoscere il LOC per punto di funzione consente di stimare lo sforzo del progetto, e da quel tempo il progetto impiegherà e il numero ottimale di sviluppatori.

Può anche influenzare il design e la scelta della lingua: ridurre i punti funzione o passare a una lingua con un LOC / FP inferiore dovrebbe ridurre lo sforzo del progetto, a parità di tutto il resto.

Le righe di codice stesse non sono molto importanti. Un modo di vederlo è confrontarlo con la prosa. La prima realizzazione è che un'importante proprietà sia del codice che della prosa (assumendo la correttezza) è la leggibilità. La leggibilità (e la comprensibilità) aiuta con altre proprietà come la manutenibilità e la correttezza.

Ci sono vantaggi nel poter adattare una funzione in un piccolo numero di linee. Ma avere un testo senza paragrafi riduce la sua leggibilità. L'uso di concetti difficili, parole difficili (rare) e modi espressivi complessi generalmente riduce la quantità di parole necessarie per esprimere un'idea, ma allo stesso tempo sposta il livello di lettura del testo dalla scuola secondaria a accademici professionisti (nel caso di prosa).

In generale è utile aggiungere astrazioni nel codice e utilizzare gli helper ecc. Ma, di nuovo, tali astrazioni possono diventare troppo numerose. Ciò che può anche accadere è che il trasferimento della complessità in un'altra parte del codice. A volte, come quando tu come esperto stai progettando un framework / libreria per l'utilizzo da parte di programmatori (o studenti) junior, è una buona idea farlo. Ma non aspettarti che i giovani siano in grado di dare un senso a come funziona il tuo codice, rendi molto difficile per loro usarlo in modo errato.

Quando si scrive il codice, in particolare non evitare di aggiungere righe vuote nel codice. Funzionano come paragrafi e ti aiutano a separare diverse parti della tua funzione (anche se non dovrebbero ancora essere inserite in helper).

Il grande problema con ogni metodo formale di valutazione del codice è che sicuramente fallirà su alcuni codici. Questo perché la programmazione è un tipo di arte e come tale non possono esistere standard chiari per la valutazione. Naturalmente ci sono diversi tipi di arte: esiste anche una produzione in serie di dipinti, e forse in questo settore è importante quanta pittura viene spesa per un dipinto. :)

Ad essere sincero, non do uno spasso sulla misurazione LOC. Certo, è bello che una funzione o una procedura sia il più breve possibile, ma prendo il codice leggibile in breve in qualsiasi momento della giornata.

Concordo sul fatto che richiedere sempre la riduzione di LOC porterebbe a un codice difficile da leggere.

Tuttavia, forse il tuo stile di codifica è troppo dettagliato e il tuo recensore ritiene che un modo più conciso sia migliore. Ad esempio, un commento che spiega solo un'affermazione abbastanza ovvia grazie alla chiara scelta dei nomi delle variabili è inutile.

C'è solo una cosa che le linee di codice misurano ed è il numero di linee di codice che hai. Tutto il resto è aria calda, speculazioni e pregiudizi.

Ci sono molti ottimi esempi nelle altre risposte su come avere un minor numero di righe di codice può rendere qualcosa di peggio, non migliore, ma un punto fondamentale sembra essere stato perso, e cioè: quante righe hai effettivamente bisogno di fare questo lavoro ?

Se per completare la tua attività sono necessarie 10 righe di codice, così sia, lo fai in 10 righe. Se per realizzarlo sono necessarie 10.000 righe, lo stesso vale per 10.000 righe. Il culto di "meno righe di codice" non migliorerà il secondo esempio se lo fai in 1.000 o 2.000 o altro. Il lavoro ha richiesto 10.000 linee e quelle 10.000 linee possono includere livelli di convalida, controllo degli errori, sicurezza, ecc. Che verrebbero persi se lo facessi in meno.

modificare

Dal momento che questo ha raccolto alcuni voti negativi, penso di dover essere più specifico su ciò che sto dicendo qui. La prima cosa che chiunque dovrebbe fare è leggere questo - il punto che ti sto chiedendo di toglierti è che il codice di alto livello che scrivi potrebbe avere poca o nessuna somiglianza con il codice della macchina che viene effettivamente eseguito. La rilevanza di questo punto è che l'attenzione al codice di alto livello senza una comprensione di ciò che accade realmente sotto è sbagliata.

Ora considera quanto segue:

• È possibile scrivere un codice lento e pessimo con una sola riga - notare il commento sull'operatore ternario alla fine del collegamento che ho fornito.

• Se una riga di codice effettua una chiamata API (o altra chiamata in una libreria esterna), per definizione hai poco in termini di controllo diretto su ciò che viene eseguito o su quanto sia efficiente.

• Il controllo degli errori, la pulizia, ecc. Aggiungono tutti righe di codice extra e sono abbastanza certo che anche il fan più accanito di un minor numero di righe di codice non si opporrebbe a questi .

Quindi, le righe di codice sono una metrica non funzionante. Un numero inferiore di righe di codice non garantisce prestazioni extra: la chiamata dell'API o della libreria è a una riga e può essere al di fuori del tuo controllo. Un numero minore di righe di codice non garantisce una maggiore robustezza: il controllo degli errori e la pulizia richiedono sempre righe aggiuntive. Un numero inferiore di righe di codice non garantisce nemmeno una maggiore leggibilità o manutenibilità: è sufficiente guardare l' IOCCC per saperlo.

Cosa garantisce un minor numero di righe di codice? Meno righe di codice, tutto qui.

È profondamente sbagliato concentrarsi sullo stesso lavoro su 2.000 righe rispetto a 10.000. Concentrati invece sul codice che funziona, che è robusto, che funziona entro le tolleranze accettate e che è più facile da leggere e mantenere in futuro. A volte ciò significa che puoi farlo in un conteggio LoC basso, a volte significa che devi farlo in un conteggio LoC più alto, ma il conteggio LoC non dovrebbe essere ciò che è importante qui.

Quanto è importante ridurre il numero di righe nel codice? Nella maggior parte dei casi, per niente. In effetti, nella maggior parte dei casi, è più importante aumentare il numero di righe di codice suddividendo operazioni complesse in passaggi più leggibili e commentando ogni passaggio, nonché aggiungendo commenti in generale per rendere il codice più leggibile ed estendibile da altri sviluppatori che vengono dopo di te.

In un periodo precedente si supponeva che se il numero di righe di codice loc è grande, allora il codice è efficace e compie tutte le attività che viene utilizzato per fare ma si è realizzato dopo qualche tempo che meno è il loc più ha l'efficienza in quanto il costo sostenuto dal sistema nell'esecuzione del codice è molto inferiore. Pertanto, per il miglioramento del sistema la loc doveva essere ridotta. Da allora si presumeva che il loc shoul fosse inferiore. Per ridurlo i seguenti fattori dovrebbe essere preso in considerazione.

1. Crea un diagramma di flusso del tuo problema
2. Prova a utilizzare meno numero di loop che puoi
3. Le chiamate di funzione non dovrebbero essere molto
4. Nuove strutture di dati come TRIE dovrebbero essere utilizzate nel caso in cui lo stack o la coda venga utilizzato per la memorizzazione delle informazioni pertinenti.
5. E cerca di risolvere il problema con un approccio realistico piuttosto che immaginativo in cui stai memorizzando un'enorme quantità di numeri in un array molto grande e quindi provando ad accedervi attraverso l'array.]
6. Utilizzare il maggior numero possibile di macro Inoltre l'approccio da utilizzare dipende anche dal problema. Se è davvero complesso, a volte l'utilizzo dell'approccio semplice equivale anche a quello complesso