Il codice dovrebbe essere breve/conciso?[Chiuso]

Question

Quando si scrive una dimostrazione matematica, uno degli obiettivi è continuare a comprimere la dimostrazione.La dimostrazione diventa più elegante ma non necessariamente più leggibile.La compressione si traduce in una migliore comprensione, poiché elimini i caratteri non necessari e la verbosità.

Sento spesso gli sviluppatori dire che dovresti ridurre il più possibile l'impronta del codice.Ciò può produrre molto rapidamente codice illeggibile.In matematica questo non è un problema poiché l'esercizio è puramente accademico.Tuttavia, nel codice di produzione in cui il tempo è denaro, chiedere alle persone di cercare di capire cosa sta facendo un codice molto conciso non sembra avere molto senso.Per un codice un po' più dettagliato, ottieni leggibilità e risparmio.

A che punto smetti di comprimere il codice software?

Answer 1

Io cerco di raggiungere un livello di verbosità, dove le mie dichiarazioni di programma lette come una condanna a qualsiasi programmatore poteva capire. Questo significa pesante refactoring il mio codice in modo tale che si tratta di tutti i piccoli pezzi di una storia, in modo che ogni azione sarebbe descritto in un metodo separato (un ancora ulteriore livello potrebbe essere quella di un'altra classe).

Significato non vorrei ridurre il mio numero di caratteri solo perché può essere espressa in meno. Questo è ciò che i concorsi di code-golf sono per.

Answer 2

La mia regola è dire quello che vuoi dire . Un modo comune che vedo le persone vanno male è "riduzione della resistenza." In sostanza, che vanno a sostituire il concetto che stanno pensando a qualcosa che sembra saltare i passaggi. Purtroppo, essi lasciano concetti dal loro codice, rendendo più difficile la lettura.

Per esempio, la modifica

for (int i = 0; i < n; i++)
    foo[i] = ...

a

int * p = foo, q = foo+n;
while ( *p++ = ... < q );

è un esempio di una riduzione della resistenza che sembra salvare i passaggi, ma lascia fuori il fatto che foo è un array, rendendo più difficile la lettura.

Un altro comune è usando bool invece di un enum.

enum {
    MouseDown,
    MouseUp
};

Avere questo essere

bool IsMouseDown;

lascia fuori il fatto che si tratta di una macchina a stati, rendendo il codice più difficile da mantenere.

Quindi la mia regola empirica sarebbe, nell'implementazione, non scavare a un livello inferiore rispetto ai concetti che si sta tentando di esprimere.

Answer 3

È possibile rendere il codice più piccolo vedendo la ridondanza e l'eliminazione, o per essere intelligente. Fare il primo e non il secondo.

Answer 4

Ecco un buon articolo di Steve McConnell - Best Practices http://www.stevemcconnell.com/ieeesoftware/bp06.htm

Penso che breve/conciso siano due risultati di un codice ben scritto.Ci sono molti aspetti per rendere buono il codice e molti risultati da un codice ben scritto, renditi conto che i due sono diversi.Non pianifichi un ingombro ridotto, pianifichi una funzione che sia concisa e faccia una singola cosa estremamente bene: questo DOVREBBE portare a un ingombro ridotto (ma potrebbe non esserlo).Ecco un breve elenco di ciò su cui mi concentrerei durante la scrittura del codice:

• singole funzioni focalizzate: una funzione dovrebbe fare solo una cosa, una consegna semplice, le funzioni multiple sono difettose e non facilmente riutilizzabili
• liberamente accoppiato: non raggiungere i dati globali dall'interno di una funzione e non fare molto affidamento su altre funzioni
• denominazione precisa: usa nomi di variabili precisi e significativi, i nomi criptici sono proprio questo
• mantieni il codice semplice e non complesso - non usare eccessivamente wow tecnici specifici della lingua, ottimo per impressionare gli altri, difficile da comprendere e mantenere facilmente - se aggiungi qualcosa di "speciale" commentalo in modo che almeno le persone possano apprezzarlo prima di imprecare sei fuori
• commento uniforme: molti commenti verranno ignorati e obsoleti, mentre pochi non avranno alcun significato
• formattazione: sii orgoglioso dell'aspetto del codice, il codice correttamente rientrato aiuta
• lavora con la mente di una persona che si occupa della manutenzione del codice: pensa a come sarebbe mantenere il codice che stai scrivendo
• sii spaventato o troppo pigro per il refactoring: niente è perfetto la prima volta, ripulisci il tuo pasticcio

Answer 5

Un modo per trovare un equilibrio è quello di cercare per leggibilità e non concisa-ness. I programmatori sono costantemente la scansione di codici visivamente per vedere cosa è stato fatto, e così il codice dovrebbe il più possibile il flusso bene.

Se il programmatore è la scansione del codice e colpisce una sezione che è difficile da capire, o richiede un certo sforzo per analizzare e comprendere visivamente, è una brutta cosa. Utilizzando comuni costrutti ben compreso è importante, stare lontano dal vago e raramente usato se non strettamente necessario.

Gli esseri umani non sono compilatori. I compilatori possono mangiare la roba e continuare a muoversi su. Codice Obscure non è mentalmente consumato dagli esseri umani nel più breve tempo compreso chiaramente il codice.

A volte è molto difficile da produrre codice leggibile in un algoritmo complicato, ma per la maggior parte, la leggibilità umana è quello che dovremmo cercare, e non l'intelligenza. Non credo che la lunghezza del codice è in realtà una misura di chiarezza sia, perché a volte un metodo più dettagliato è più leggibile di un metodo conciso, e, talvolta, un metodo sintetico è più leggibile di una lunga.

Inoltre, i commenti devono integrare solo, e non dovrebbero descrivere il codice, il codice dovrebbe descrivere se stessa. Se si dispone di commentare una linea perché non è ovvio ciò che viene fatto, che è male. Ci vuole più tempo per la maggior parte dei programmatori esperti di leggere una spiegazione inglese di quanto non faccia per leggere il codice stesso. Credo che i martelli libro completo di codice questa casa.

Answer 6

Per quanto riguarda i nomi degli oggetti vanno, il pensiero su questo è passato attraverso un'evoluzione con l'introduzione di nuovi linguaggi di programmazione.

Se si prendono le lingue "ricci brace", a partire da C, brevità era considerato l'anima di spirito. Quindi, si dovrebbe avere una variabile per contenere un valore del prestito denominato "LV", per esempio. L'idea era che stavate scrivendo un sacco di codice, in modo da mantenere le sequenze di tasti al minimo.

Poi è arrivato il Microsoft-sanzionato "la notazione ungherese", dove le prime lettere di un nome di variabile sono stati pensati per indicare il tipo di fondo. Si potrebbe usare "flv", o qualcosa del genere, per indicare che il valore del prestito è stato rappresentato da una variabile float.

Con Java, e quindi C #, il paradigma è diventato uno dei chiarezza. Un buon nome per una variabile valore del prestito sarebbe "loanValue". Credo che parte della ragione di questo è la funzione di comando di completamento nella maggior parte dei redattori moderni. Dal momento che la sua non è necessario digitare l'intero nome di più, si potrebbe anche usare i caratteri che è necessario per essere descrittivo.

Questo è un buon andamento. Codice deve essere intelligibile. I commenti sono spesso aggiunti in un secondo tempo, se non del tutto. Non sono inoltre aggiornati come codice viene aggiornato, in modo che diventino obsolete. Descrittiva, ben scelto , i nomi delle variabili sono il primo modo, migliore e più semplice per far sapere agli altri quello che la codifica circa.

Ho avuto un professore di informatica che ha detto "Come ingegneri, siamo costantemente alla creazione di tipi di cose che prima non esistevano. I nomi che diamo li bastone, quindi dovremmo stare attenti a nominare le cose significato ".

Answer 7

Ci deve essere un equilibrio tra il codice sorgente dolce breve e le prestazioni. Se è bello sorgente e gestisce il più veloce, allora bene, ma per il bene della bella fonte corre come un cane, poi male.

Answer 8

Si sforzano di refactoring fino a che il codice stesso legge bene. Scoprirete i propri errori nel processo, il codice sarà più facile Grok per il "prossimo ragazzo", e non sarà gravato da mantenere (e poi dimenticarsi di cambiare) nei commenti quello che stai già espresso in codice.

Quando questo non funziona ... certo, mi lasciare un commento.

E non mi dica "che cosa" nel commento (che è ciò che il codice è per), mi dica "perché".

Answer 9

Al contrario di lungo / vagante? Certo!

Ma si arriva al punto in cui è così breve e così conciso che è difficile da capire, allora sei andato troppo lontano.

Answer 10

Sì. Sempre.

Answer 11

DRY : Non Repeat Yourself. Che vi darà un codice che sia conciso e sicuro. Scrivendo lo stesso codice più volte è un buon modo per rendere più difficile mantenere.

Ora questo non significa che si dovrebbe fare in funzione di eventuali blocchi di codice in modalità remota in cerca allo stesso modo.

Un errore molto comune (horror?) Per esempio è fattorizzare il codice a fare quasi la stessa cosa, e per gestire le differenze tra occorrenze con l'aggiunta di un flag per funzione API. Questo può sembrare inocuous in un primo momento, ma genera flusso di codice difficile da capire e bug prona, e ancora più difficile il refactoring.

Se si seguono le regole comuni di refactoring (cercando di codice odori) il codice diventerà sempre più concisa come effetto collaterale, come molti odori di codice sono sul rilevamento ridondanza.

D'altra parte, se si tenta di rendere il codice più breve possibile, non a seguito di eventuali linee guida meaningfull, ad un certo punto si dovrà fermare perché proprio non vedrà più come ridurre il codice.

Provate a immaginare se il primo passo è la rimozione di tutti gli spazi bianchi inutili ... dopo che il codice passo nella maggior parte dei linguaggi di programmazione diventerà così difficile da leggere non avrete molte possibilità di trovare qualsiasi altro miglioramento possibile.

L'esempio precedente è piuttosto caricaturale, ma non così lontano da quello che si ottiene quando si cerca di ottimizzare per dimensione senza seguire alcuna linea guida sensibile.

Answer 12

Non c'è nessuna linea precisa che si può trarre a distinguere il codice che è glib e codice che è fiorito. Usate il vostro giudizio migliore. Avere altri guardano il codice e vedere come facilmente si può capire. Ma ricordate, la correttezza è il numero 1 gol.

Answer 13

La necessità di impronte di codice di piccole dimensioni è un ritorno dai giorni di linguaggio assembly e le prime lingue po 'di alto livello ... non piccole impronte codice in cui una vera e urgente. In questi giorni, però, la sua non tanto di una necessità.

Detto questo, io odio il codice verbose. Dove lavoro, scriviamo codice che legge il più possibile come un linguaggio naturale, senza alcun extra o di grammatica parole. E non abbreviamo niente meno che il suo un'abbreviazione molto comune.

Company.get_by_name("ABC") 
makeHeaderTable()

è quanto di più stringata come andiamo.

Answer 14

In generale, io faccio le cose ovvie e facile da lavorare. Se la concisione / brevità mi serve a tal fine, tanto meglio. Spesso risposte brevi sono la più chiara, per cui la brevità è un sottoprodotto della ovvia.

Answer 15

Ci sono un paio di punti in mente che determinano quando interrompere l'ottimizzazione:

• Vale la pena di passare del tempo l'esecuzione di ottimizzazioni. Se si dispone di persone che spendono settimane e non trovare nulla, ci sono migliori usi di tali risorse?

• Qual è l'ordine di priorità di ottimizzazione. Ci sono alcuni fattori che si potrebbe prestare attenzione quando si tratta di codice: il tempo di esecuzione, lo spazio di esecuzione (sia in esecuzione e solo il codice compilato), la scalabilità, la stabilità, il numero di funzioni sono implementate, ecc Parte di questo è il commercio fuori del tempo e dello spazio, ma può anche essere dove non certo codice andare, ad esempio, può middleware di eseguire comandi hoc ad SQL oppure se esse essere instradati attraverso le stored procedure per migliorare le prestazioni?

Credo che il punto principale è che c'è un moderazione che la maggior parte buone soluzioni avranno.

Answer 16

Le ottimizzazioni del codice hanno poco a che fare con lo stile di codifica. Il fatto che il file contiene spazi x o di nuove linee in meno rispetto all'inizio non lo rende migliore o più veloce, almeno nella fase di esecuzione - si formatta il codice con caratteri bianchi che sono unsually ignorati dal compilatore. Rende anche il codice di peggio, perché diventa illeggibile per gli altri programmatori e voi stessi.

E 'molto più importante per il codice sia breve e pulito nella sua struttura logica, come le condizioni di prova, il flusso di controllo, assunzioni, gestione degli errori l'interfaccia di programmazione generale. Naturalmente, vorrei includere anche qui intelligente e utile commenti + documentazione.

Answer 17

Non v'è necessariamente una correlazione tra il codice conciso e prestazioni. Questo è un mito. In linguaggi maturi come C / C ++ i compilatori sono in grado di ottimizzare il codice in modo molto efficace. V'è motivo necessità in tali lingue supporre che il codice più conciso è il codice migliore rendimento. Più recenti, lingue meno prestazioni ottimizzate come Ruby mancano le funzioni di ottimizzazione del compilatore di C / C ++ compilatori, ma c'è ancora poca ragione di credere che il codice conciso è meglio performante. La realtà è che non sappiamo mai quanto bene il codice si esibirà nella produzione fino a quando non entra in produzione e si profila. Semplice, innocui, le funzioni possono essere enormi colli di bottiglia delle prestazioni, se chiamato da posizioni abbastanza all'interno del codice. Nei sistemi altamente concorrenti più grandi strozzature sono generalmente causati da algoritmi concorrenza povere o bloccaggio eccessivo. Questi problemi sono raramente risolti scrivendo codice "concisa".

La linea di fondo è questa: Il codice che funziona male può sempre essere riscritta volta profiling determina è il collo di bottiglia. Il codice può essere efficacemente refactoring solo se è facile da capire. Il codice che è scritto di essere "concisa" o "intelligente" è spesso più difficile da refactoring e mantenere.

Scrivere il codice per migliorare la leggibilità umana quindi refactoring per le prestazioni in caso di necessità.

I miei due centesimi ...

Answer 18

Codice dovrebbe essere breve, concreta, e concentrato. È sempre possibile spiegare le tue idee con molte parole in commenti .

Answer 19

È possibile rendere il codice più breve o compatta come ti piace il tempo che commentarlo. In questo modo il codice può essere ottimizzato, ma ancora fare sence. Io tendo a stare in mezzo da qualche parte con le variabili e metodi descrittivi e commenti sparce se non è ancora chiaro.