Cosa significa scrivere "buon codice"? [chiuso]

In questa domanda ti ho chiesto se essere un cattivo scrittore ti impedisce di scrivere un buon codice. Molte delle risposte sono iniziate con "dipende da cosa intendi per buon codice".

Sembra che il termine "buon codice" e "cattivo codice" siano molto soggettivi. Dal momento che ho un punto di vista, potrebbe essere molto diverso dal punto di vista degli altri.

Cosa significa scrivere "buon codice"? Che cos'è il "buon codice"?

Un buon programmatore è come un buon giocatore di biliardo.

Quando vedi un giocatore di biliardo professionista, all'inizio potresti non essere colpito: "Certo, hanno messo tutte le palle dentro, ma avevano solo tiri facili!" Questo perché, quando un giocatore di biliardo sta facendo il suo tiro, non pensa a quale palla andrà in una tasca, ma pensa anche a dove finirà la pallina . Prepararsi per lo scatto successivo richiede abilità e pratica straordinarie, ma significa anche che sembra facile.

Ora, portando questa metafora al codice, un buon programmatore scrive codice che sembra facile e diretto da fare . Molti degli esempi di Brian Kernighan nei suoi libri seguono questo schema. Parte del "trucco" è trovare una corretta concettualizzazione del problema e della sua soluzione . Quando non comprendiamo abbastanza bene un problema, abbiamo maggiori probabilità di complicare eccessivamente le nostre soluzioni e non riusciremo a vedere idee unificanti.

Con una corretta concettualizzazione del problema, ottieni tutto il resto: leggibilità, manutenibilità, efficienza e correttezza. Poiché la soluzione sembra così semplice, probabilmente ci saranno meno commenti, poiché non sono necessarie ulteriori spiegazioni. Un buon programmatore può anche vedere la visione a lungo termine del prodotto e formarne le concettualizzazioni di conseguenza.

( originale )

EDIT: L'idea di base è che la "qualità del codice" non può essere inserita nelle regole, allo stesso modo in cui non puoi mettere "buona arte" o "buona poesia" nelle regole in modo da poter lasciare che un computer determini dire "Sì, buona arte" o "No, cattiva poesia". Attualmente l'unico modo è vedere quanto sia facilmente comprensibile il codice per gli altri umani.

Non ci sono davvero buoni criteri oltre a quanto velocemente puoi capire il codice. Rendi bello il tuo codice trovando il perfetto compromesso tra succinto e leggibilità.

Il "WTF al minuto" (sopra) è vero ma è solo un corollario della regola più generale. Più WTFs più lenta è la comprensione.

Sai di scrivere un buon codice quando ...

1. Il cliente è contento
2. Compagni colleghi 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 da usare per il team
5. Guardi il codice che scrivi oggi e dici a te stesso "Vorrei aver scritto un codice come questo due anni fa"

Come si misura se il codice è buono ...

• Qual è il tempo di risposta?
• Quanti viaggi di andata e ritorno sul server fanno?
• Utilizzeresti personalmente l'applicazione o pensi che sia ingombrante?
• La costruiresti allo stesso modo la prossima volta?

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

Un codice che è

1. senza bug

2. riutilizzabile

3. indipendente

4. meno complesso

5. Ben documentato

6. facile da chage

si chiama buon codice.

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

Fonte: MSDN

Ti sembra familiare?

Philips mi ha dato l'opportunità di guardare il design di un nuovo prodotto. Man mano che si sviluppava, divenni sempre più a disagio e iniziai 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 i miei gusti e voleva sapere quale criterio stavo usando per esprimere il mio giudizio. Non sono stato in grado di dirglielo! Poiché non riuscivo a spiegare quali principi fossero stati violati, i miei commenti venivano semplicemente ignorati e il lavoro continuava. Sentendo che ci deve essere un modo per spiegare e fornire motivazione per il mio "gusto", Ho iniziato a cercare un principio che distinguesse i buoni disegni da quelli cattivi. Gli ingegneri sono molto pragmatici; possono ammirare la bellezza, ma cercano utilità. Ho cercato di trovare una spiegazione del perché la "bellezza" fosse utile.

Vedi il resto qui .

a parte i criteri di qualità del codice naturale (copia / incolla minima, niente spaghetti, ecc.) un buon codice industriale dovrebbe sempre apparire 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;

al contrario di

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

Forse una risposta illustrando il contrario sarebbe di aiuto (in più è una scusa per far entrare XKCD qui).

Il buon codice è

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

Esempi inclusi

• Apache Commons
• Quadro di primavera
• Quadro di ibernazione

Andrò semplicemente con "mantenibile"

Tutto il codice deve essere mantenuto: non è necessario che l'attività sia resa più difficile del necessario

Se un lettore non comprende questo semplice requisito o ne ha bisogno, è necessario che il lettore non stia scrivendo codice ...

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

• Come è organizzato il progetto? I file sorgente sono organizzati in modo pulito e posso trovare il codice senza troppi sforzi?
• Come è organizzato il codice? È chiaramente documentato cosa fa il codice nel file, ad esempio tramite l'uso di un'intestazione del file o tramite l'uso di ciascuna classe che risiede nel proprio file? Esistono funzioni nel file che non vengono più utilizzate nell'applicazione?
• 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 verso di esso ed evita strutture di controllo non necessarie? Tutto è chiaramente documentato con il codice che si auto documenta dove è necessario e i commenti esprimono chiaramente il perché e / o il modo in cui sta facendo il codice?

Oltre a tutto ciò, il design dell'applicazione ha senso nel suo insieme? Il codice che risiede nell'applicazione può essere il migliore al mondo, ma potrebbe comunque essere una seccatura lavorare se la progettazione generale dell'applicazione non ha senso.

Consentitemi gentilmente di non essere d'accordo sulla leggibilità. No, non del tutto: un buon codice dovrebbe essere leggibile e ciò può essere facilmente ottenuto con abbastanza commenti.

Ma considero due tipi di WTF: quelli in cui ti chiedi se il programmatore è andato oltre la programmazione 101, e quelli in cui non capisci assolutamente la genialità del codice. All'inizio un po 'di codice può sembrare molto strano, ma in realtà è una soluzione molto inventiva per un problema difficile. Il secondo non dovrebbe essere conteggiato nel contatore WTF e può essere evitato dai commenti.

Il codice molto leggibile può essere molto, molto lento. Una soluzione meno leggibile può offrire un miglioramento di moltiplicatore della velocità. R è un ottimo esempio di una lingua in cui ciò è spesso vero. A uno piace evitare il più possibile i loop for lì. In generale, considererei il codice più veloce il codice migliore anche se è meno leggibile. Cioè, se il miglioramento è sostanziale, ovviamente, 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 nell'uso della memoria: ci sono solo più oggetti creati. In alcuni casi l'uso intelligente della memoria rende di nuovo il codice meno leggibile. Ma se si destreggia tra gigabyte di sequenze di DNA, ad esempio, la memoria è un fattore cruciale. Ancora una volta, considero il codice meno dispendioso in termini di memoria il codice migliore, indipendentemente dalla leggibilità.

Quindi sì, la leggibilità è importante per un buon codice. Conosco l'adagio di Uwe Liggis: pensare che il male e il computer siano economici. Ma nel mio campo (genomica statistica), i tempi di calcolo di una settimana e l'utilizzo 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ù.

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 saltare e capire cosa sto facendo senza che io superi ogni blocco di codice e mostrando quello che sta facendo.
Invece di dire: "Aspetta un minuto, cosa ?!" Sta dicendo: "Oh, ok, vedo cosa hai fatto lì."

Il buon codice inoltre non ha molte soluzioni alternative o "hack" subdoli. Righe quando, mentre lo scrivi, stai anche dicendo a te stesso: "So che questo non è un buon modo per farlo, ma per ora dovrò farlo in questo modo. me stesso per migliorarlo in seguito ... "

Esistono molte caratteristiche del codice "buono", ma le più importanti, IMHO, sono la leggibilità e la manutenibilità.

Il tuo codice sarà contenere bug, sarà probabilmente esteso e riutilizzato, e dovrebbe essere ri-scomposto ad un certo punto - anche se si tratta si ri-visitarla, le probabilità sono che non si avrà un'idea di cosa diavolo in primo luogo, hai fatto un favore a te stesso e non creare ostacoli.

Certo, usa quell'algoritmo complesso ma estremamente efficiente, ma assicurati di dedicare un po 'di tempo extra a documentarlo, ma altrimenti rendi il tuo codice chiaro e coerente.