Cosa significa scrivere “ buon codice ”? [chiuso]

Non ci sono altri criteri validi di quanto velocemente puoi capire il codice. Puoi migliorare il tuo codice trovando il compromesso perfetto tra succintà e leggibilità.

Le “WTF” al minuto “(sopra) è vero ma è solo un corollario della regola più generale. Maggiore è il numero di WTF, più lenta sarà la comprensione.

Commenti

• @rmx: define " facendo il lavoro beh "
• Bene, questo metodo RemoveCustomer rimuove effettivamente il cutomer senza rovinare tutto. Puoi passare ore a farlo sembrare carino, ma ciò non significa che funzioni davvero. ' La velocità con cui puoi capire il codice ' non è lunico criterio per ' un buon codice ' è ciò che ' sto dicendo.
• @rmx: ma essere privi di bug è implicito, non è ' vero? Se il tuo codice non ' funziona correttamente, ' non è (ancora) codice.
• @ rmx: infatti no. Se il tuo codice è facile da capire, in conclusione è ' facile da capire se lo fa ' male. OTOH, se ' è difficile da capire, ' è difficile da capire se è così ' è proprio un lavoro.
• @rmx: PS in parole povere, il tuo decrement () è un classico WTF e quindi rallenta la comprensione delle parti di codice in cui viene utilizzata questa funzione

Sai di scrivere un buon codice quando …

1. Il cliente è felice
2. I colleghi di lavoro prendono in prestito il tuo codice come punto di partenza
3. Al ragazzo / ragazza nuovo di zecca è stato appena detto di apportare modifiche a un sistema che hai costruito 6 mesi fa e non ti ha mai fatto una domanda
4. Il tuo capo ti chiede di sviluppare nuovi widget per il team da usare
5. Guardi il codice che scrivi oggi e dici a te stesso “Vorrei aver scritto un codice come questo due anni fa”

Come fai misurare se il codice è buono …

• Qual è il tempo di risposta?
• Quanti round trip al server fa?
• Utilizzeresti personalmente lapplicazione o pensi che sia goffa?
• La costruiresti allo stesso modo la prossima volta?

Un buon codice funziona quando è dovrebbe. Un buon codice può essere facilmente modificato quando necessario. Un buon codice può essere riutilizzato per realizzare un profitto.

Commenti

• " Il cliente è felice " è ortogonale a questo.
• @TRA – Se il cliente è felice, significa che hai compreso i requisiti e fornito una soluzione che si aspettava.
• certo ma un codice errato può fare lo stesso.

Un codice che è

1. privo di bug

2. riutilizzabile

3. indipendente

4. meno complesso

5. ben documentato

6. facile da modificare

si chiama buon codice.

Un buon programma funziona perfettamente e non ha bug. Ma quali qualità interne producono una tale perfezione? Non è un mistero, abbiamo solo bisogno di qualche promemoria occasionale. Sia che tu codifichi in C / C ++, C #, Java, Basic, Perl, COBOL o ASM, tutta una buona programmazione mostra le stesse qualità consolidate: semplicità, leggibilità, modularità , stratificazione, design, efficienza, eleganza e chiarezzaefficienza, eleganza e chiarezza

Fonte: MSDN

Commenti

• Semplicità, leggibilità, eleganza e chiarezza sono la stessa cosa. Modularità e stratificazione sono solo metodi per rendere chiaro il tuo codice ed elegante. Lunica cosa rimasta nellelenco è lefficienza, che è un po implicita, e inoltre è spesso una questione di compromesso tra efficienza e chiarezza.
• Controlla questo: goo.gl/hdQt8
• Il codice può essere privo di bug?
• No, può ' t. (Praticamente)
• Efficiente dovrebbe essere aggiunto alla tua lista. La velocità non è ' t necessaria Arily un indicatore primario di buon codice, ma un buon codice non dovrebbe ' essere inutilmente lento o dispendioso.

Ti sembra familiare?

Philips mi ha dato lopportunità di vedere il design di un nuovo prodotto. Man mano che si sviluppava, sono diventato sempre più a disagio e ho iniziato a confidare le mie preoccupazioni al mio supervisore. Gli ho ripetutamente detto che i disegni non erano “puliti” e che dovevano essere “belli” nel modo in cui i disegni di Dijkstra erano belli. Non ha trovato questo un commento utile.Mi ha ricordato che eravamo ingegneri, non artisti. Nella sua mente stavo semplicemente esprimendo il mio gusto e voleva sapere quale criterio stavo usando per esprimere il mio giudizio. Non sono riuscito a dirglielo! Poiché non potevo spiegare quali principi fossero stati violati, i miei commenti furono semplicemente ignorati e il lavoro continuò. Sentendo che doveva esserci un modo per spiegare e motivare il mio “gusto”, ho iniziato a cercare un principio che distinguesse i progetti buoni da quelli cattivi. Gli ingegneri sono molto pragmatici; possono ammirare la bellezza, ma cercano lutilità. Ho cercato di trovare una spiegazione del motivo per cui “beauty” era utile.

Per favore guarda il resto qui .

Commenti

• Poiché il collegamento in @mlvljr ' il post è interrotto , ecco un link alla pagina di Google Libri: books.google.co.in/…
• @balajeerc Grazie (ho anche corretto il collegamento, quindi punta a una versione ospitata da Springer dello stesso pdf) 🙂

a parte i criteri di qualità del codice naturale (copia / incolla minima, niente spaghetti, ecc.) un buon codice industriale dovrebbe sempre sembrare un po ingenuo, un po troppo prolisso, come

int key = i; const bool do_not_create = false; Record r = cache.get(key, do_not_create); ++i; 

in contrapposizione a

Record r = cache.get(i++, false); 

Commenti

• Ma do_not_create = false significa “passare false come argomento do_not_create in modo che verrà creato “o” pas s false come argomento do_create in modo che non venga creato “? In una lingua in cui puoi utilizzare i nomi degli argomenti, preferirei cache.get (key:i, create: false); i += 1;.

Forse una risposta che illustri il contrario sarebbe daiuto (in più è” una scusa per inserire XKCD qui).

Un buon codice è

• semplice da capire,
• facile da mantenere ,
• non cerca di risolvere tutti i problemi solo quello a portata di mano
• sopravvive a lungo senza che gli sviluppatori cerchino alternative

Gli esempi includono

• Apache Commons
• Framework Spring
• Framework Hibernate

Vado semplicemente con “manutenibile”

Tutto il codice deve essere mantenuto: non cè bisogno che questo compito sia reso più difficile del necessario

Se un lettore non comprende questo semplice requisito o ha bisogno che sia spiegato, quel lettore non dovrebbe scrivere codice …

Un buon codice sarà diverso per ogni persona e la lingua con cui stanno lavorando ha anche un impatto su ciò che potrebbe essere considerato essere un buon codice. Generalmente quando mi avvicino a un progetto cerco le seguenti cose:

• Comè organizzato il progetto? I file sorgente sono organizzati in modo pulito e posso trovare il codice senza troppi sforzi?
• Comè organizzato il codice? È chiaramente documentato ciò che fa il codice nel file, ad esempio attraverso luso di unintestazione di file, o attraverso luso di ogni classe che risiede nel proprio file? Nel file sono presenti funzioni che non vengono più utilizzate nellapplicazione?
• Come sono organizzate le funzioni? Esiste un modello chiaro in cui vengono dichiarate le variabili o è un modello abbastanza casuale? Il codice ha un flusso logico ed evita strutture di controllo non necessarie? È tutto chiaramente documentato con il codice che si documenta da solo dove è necessario e i commenti esprimono chiaramente il perché e / o come di ciò che il codice sta facendo?

Oltre a tutto questo, il design del lapplicazione ha senso nel suo complesso? Il codice che risiede nellapplicazione può essere il migliore al mondo, ma potrebbe comunque essere un problema lavorarci se il design complessivo dellapplicazione non ha senso.

Lasciatemi gentilmente dissentire sulla leggibilità. No, non completamente: un buon codice dovrebbe essere leggibile e ciò può essere facilmente ottenuto con un numero sufficiente di commenti.

Ma considero due tipi di WTF: quelli in cui ti chiedi se il programmatore sia andato oltre la programmazione 101 e quelli in cui non afferri assolutamente la genialità del codice. Alcuni codici possono sembrare molto strani primo, ma in realtà è una soluzione molto creativa a un problema difficile. Il secondo non dovrebbe contare nel misuratore WTF e può essere evitato dai commenti.

Un codice molto leggibile può essere molto, molto lento . Una soluzione meno leggibile può dare un miglioramento di molte volte nella velocità. R è un ottimo esempio di un linguaggio in cui spesso è vero. Ci piace evitare il più possibile i cicli for.In generale, considererei il codice più veloce il codice migliore anche se è meno leggibile. Cioè, se il miglioramento è sostanziale fuori rotta e vengono inseriti abbastanza commenti per spiegare cosa fa il codice.

Inoltre, la gestione della memoria può essere cruciale in molte applicazioni scientifiche. Il codice che è molto leggibile, tende ad essere un po sciatto nelluso della memoria: ci sono solo più oggetti creati. In alcuni casi un uso intelligente della memoria rende il codice ancora meno leggibile. Ma se giochi a gigabyte di sequenze di DNA, ad esempio, la memoria è un fattore cruciale. Di nuovo, considero il codice che richiede meno memoria, il codice migliore, indipendentemente dalla leggibilità.

Quindi sì, la leggibilità è importante per un buon codice. Conosco ladagio di Uwe Liggis: pensare fa male ei computer costano poco. Ma nel mio campo (genomica statistica), i tempi di calcolo di una settimana e lutilizzo della memoria di oltre 40 Gb non sono considerati anormali. Quindi un miglioramento del doppio della velocità e della metà della memoria vale molto di più di quel pizzico di leggibilità in più.

Commenti

• Nessuna regola / regola senza eccezioni
• Vorrei essere in disaccordo con il tuo disaccordo: dici che nel tuo campo la velocità è molto importante e dici che è più importante della leggibilità. Non sono daccordo, dovresti sforzarti di usare il giusto equilibrio. Se la velocità non è necessaria, ad esempio per uninterfaccia di alto livello, potresti preferire qualcosa di facile da mantenere, se è necessaria la velocità allora sono daccordo con te. Piuttosto che regole rigide, è meglio usare il buon senso e dovresti comunque evitare unottimizzazione prematura.
• @BlueTrin Perché non compilano entrambi questi codici sorgente hi-perf e documentano anche linferno di cosa ' sta succedendo lì (proprio lì nei commenti)?

Per quanto mi riguarda … so che sto scrivendo un buon codice quando arriva un collega che lavora su un altro progetto ed è in grado di entrare e capire cosa sto facendo senza che io vada oltre ogni blocco di codice e mostrando cosa sta facendo.
Invece di dire: “Aspetta un minuto, cosa ?!” Sta dicendo: “Oh, ok, vedo cosa hai fatto lì”.

Anche un buon codice non “ha molte soluzioni alternative o” hack “. Righe quando, mentre “lo stai scrivendo”, stai anche dicendo a te stesso: “So che questo non è un buon modo per farlo, ma dovrò farlo in questo modo per ora. “Ricorderò a me stesso di migliorarlo in seguito …”

Ci sono molte caratteristiche del codice “buono” , ma le più importanti, IMHO, sono la leggibilità e la manutenibilità.

Il tuo codice conterrà bug, probabilmente sarà esteso e riutilizzato e dovrebbe essere nuovamente scomposto a un certo punto – anche se lo stai visitando di nuovo, è probabile che non avrai la più pallida idea di cosa diavolo hai fatto in primo luogo, di fare un favore a te stesso e non mettere ostacoli.

Certo, usa quellalgoritmo complesso ma super efficiente, ma assicurati di dedicare un po di tempo in più a documentarlo, altrimenti fai in modo che il tuo codice chiaro e coerente.