Che aspetto ha il codice di un buon programmatore? [chiuso]

Sono un programmatore hobbista (ho iniziato con VBA per rendere Excel più veloce) e ho lavorato con VB.NET / C # .NET e sto cercando di imparare ADO.NET.

Un aspetto della programmazione che mi ha sempre frustrato è che aspetto ha "buono"? Non sono un professionista quindi ho poco con cui confrontarmi. Cosa rende un programmatore migliore? È:

• Hanno una migliore comprensione di tutti gli oggetti / classi / metodi in una data lingua?
• I loro programmi sono più efficienti?
• Il design dei loro programmi è molto migliore in termini di migliore documentazione, buona scelta di nomi per le funzioni, ecc.?

In altre parole, se dovessi guardare il codice di un programmatore professionista, qual è la prima cosa che noterei del loro codice rispetto al mio? Ad esempio, leggo libri come "Professional ASP.NET" di Wrox press. Gli esempi di codice in quel libro sono di "classe mondiale"? È questo l'apice? Qualche programmatore di punta guarderebbe quel codice e penserebbe che sia un buon codice?

L'elenco che segue non è completo, ma queste sono le cose a cui ho pensato nel considerare la tua domanda.

• Un buon codice è ben organizzato. I dati e le operazioni nelle classi combaciano. Non ci sono dipendenze estranee tra le classi. Non sembra "spaghetti".

• Buoni commenti sul codice spiegano perché le cose vengono fatte non ciò che viene fatto. Il codice stesso spiega cosa viene fatto. La necessità di commenti dovrebbe essere minima.

• Un buon codice utilizza convenzioni di denominazione significative per tutti gli oggetti tranne il più transitorio. il nome di qualcosa è informativo su quando e come usare l'oggetto.

• Un buon codice è ben testato. I test servono come specifica eseguibile del codice ed esempi del suo utilizzo.

• Un buon codice non è "intelligente". Fa le cose in modi semplici e ovvi.

• Un buon codice è sviluppato in unità di calcolo piccole e di facile lettura. Queste unità vengono riutilizzate in tutto il codice.

Non l'ho ancora letto, ma il libro che ho intenzione di leggere su questo argomento è Clean Code di Robert C. Martin.

La prima cosa che noterai è che il loro codice segue uno stile di codifica coerente . Scrivono sempre gli stessi blocchi di struttura, rientrano religiosamente e commentano dove appropriato.

La seconda cosa che noteresti è che il loro codice è segmentato in piccoli metodi / funzioni che coprono non più di un paio di dozzine di righe al massimo. Usano anche nomi di metodi auto descrittivi e generalmente il loro codice è molto leggibile.

La terza cosa che noterai, dopo aver pasticciato un po 'con il codice, è che la logica è facile da seguire, facile da modificare e quindi facilmente gestibile.

Successivamente, avrai bisogno di una certa conoscenza ed esperienza nelle tecniche di progettazione del software per comprendere le scelte specifiche che hanno preso per costruire la loro architettura di codice.

Per quanto riguarda i libri, non ho visto molti libri in cui il codice potrebbe essere considerato "di classe mondiale". Nei libri cercano principalmente di presentare esempi semplici, che potrebbero essere rilevanti per la risoluzione di problemi molto semplici ma non riflettono situazioni più complesse.

Citando Fowler, riassumendo la leggibilità:

Qualsiasi sciocco può scrivere codice che un computer può capire.
I bravi programmatori scrivono codice che gli esseri umani possono capire.

'nough ha detto.

Personalmente, dovrò citare "The Zen of Python" di Tim Peters. Dice ai programmatori Python come dovrebbe essere il loro codice, ma trovo che si applichi praticamente a tutto il codice.

Bello è meglio che brutto.
Esplicito è meglio che implicito.
Semplice è meglio che complesso.
Complesso è meglio che complicato.
Flat è meglio che annidato.
Sparse è meglio di dense.
La leggibilità conta.
I casi speciali non sono abbastanza speciali da infrangere le regole.
Anche se la praticità batte la purezza.
Gli errori non dovrebbero mai passare in silenzio.
A meno che non sia esplicitamente messo a tacere.
Di fronte all'ambiguità, rifiuta la tentazione di indovinare.
Dovrebbe esserci un modo ovvio, e preferibilmente solo uno, per farlo.
Anche se in questo modo potrebbe non essere ovvio all'inizio, a meno che tu non sia olandese.
Adesso è meglio che mai.
Anche se spesso non è mai meglio diproprio ora.
Se l'implementazione è difficile da spiegare, è una cattiva idea.
Se l'implementazione è facile da spiegare, potrebbe essere una buona idea.
Gli spazi dei nomi sono una grande idea clamorosa: facciamo di più di quelli!

Il codice è poesia.

Inizia da questo punto di logica e puoi derivare molte delle qualità desiderabili del codice. Soprattutto, osserva che il codice viene letto molto più di quanto non sia scritto, quindi scrivi codice per il lettore. Riscrivi, rinomina, modifica e refactoring per il lettore.

Un seguito sul corollario:

Il lettore sarai tu all'istante n dalla data di creazione del codice. Il payoff della scrittura del codice per il lettore è una funzione monotonicamente crescente di n. Un lettore che guarda il tuo codice per la prima volta è indicato da n == infinito.

In altre parole, maggiore è l'intervallo di tempo da quando hai scritto il codice a quando rivedi il codice, più apprezzerai i tuoi sforzi di scrivere per il lettore. Inoltre, chiunque consegni il tuo codice trarrà grandi vantaggi dal codice scritto con il lettore come considerazione principale.

Un secondo corollario:

Il codice scritto senza considerazione per il lettore può essere inutilmente difficile da capire o da usare. Quando il corrispettivo per il lettore scende al di sotto di una certa soglia, il lettore ricava dal codice un valore inferiore rispetto a quello ottenuto riscrivendo il codice. Quando ciò accade, il codice precedente viene gettato via e, tragicamente, molto lavoro viene ripetuto durante la riscrittura.

Un terzo corollario:

È noto che il secondo corollario si ripete più volte in un circolo vizioso di codice scarsamente documentato seguito da riscritture forzate.

Sto programmando da 28 anni e trovo che questa sia una domanda difficile a cui rispondere. Per me un buon codice è un pacchetto completo. Il codice è scritto in modo pulito, con nomi significativi di variabili e metodi. Ha commenti ben posizionati che commentano l'intento del codice e non rigurgitano solo il codice che puoi già leggere. Il codice fa ciò che dovrebbe in modo efficiente, senza sprecare risorse. Deve anche essere scritto con un occhio alla manutenibilità.

La conclusione però è che significa cose diverse per persone diverse. Quello che potrei etichettare come un buon codice che qualcun altro potrebbe odiare. Un buon codice avrà alcuni tratti comuni che penso di aver identificato sopra.

La cosa migliore che puoi fare è esporti al codice. Guarda il codice di altre persone. I progetti Open Source sono una buona fonte per questo. Troverai un buon codice e un codice errato. Più lo guardi, meglio riconoscerai ciò che ritieni essere un buon codice e un cattivo codice.

Alla fine sarai il tuo giudice. Quando trovi stili e tecniche che ti piacciono, adottali, nel tempo ti verrà in mente il tuo stile e questo cambierà nel tempo. Non c'è persona qui che può agitare una bacchetta e dire ciò che è buono e che qualsiasi altra cosa è cattiva.

Leggi il libro Code Complete. Questo spiega molte idee su come strutturare il codice e le ragioni per farlo. La lettura dovrebbe far cortocircuitare il tuo tempo per acquisire l'esperienza necessaria per distinguere il bene dal male.

http://www.amazon.com/Code-Complete-Practical-Handbook-Construction/dp/0735619670/ref=pd_bbs_sr_1?ie=UTF8&s=books&qid=1229267173&sr=8-1

Avendo programmato io stesso da quasi 10 anni e avendo lavorato con altri, posso dire senza pregiudizi che non c'è differenza tra un buon programmatore e un codice di programmatore medio

Tutti i programmatori a livello competente:

• Commenta correttamente
• Struttura efficiente
• Documento in modo pulito

Una volta ho sentito un collega dire " Sono sempre stato molto logico e di mentalità razionale. Penso che sia per questo che mi piace sviluppare "

Questa, secondo me, è la mente di un programmatore medio. Uno che vede il mondo in termini di regole e logica e alla fine obbedisce a quelle regole quando progetta e scrive un programma.

Il programmatore esperto, capisce le regole, ma anche il loro contesto. Questo alla fine li porta a proporre nuove idee e implementazioni, il marchio di un programmatore esperto. La programmazione è in definitiva una forma d'arte.

In poche parole, il codice di un buon programmatore può essere letto e compreso.

A mio parere, il codice di un buon programmatore è indipendente dal linguaggio ; un codice ben scritto può essere letto e compreso in un breve lasso di tempo con il minimo pensiero, indipendentemente dal linguaggio di programmazione utilizzato. Che il codice sia in Java, Python, C ++ o Haskell, il codice ben scritto è comprensibile da persone che non programmano nemmeno in quel particolare linguaggio.

Alcune caratteristiche del codice che è facile da leggere sono, metodi che sono ben denominati, assenza di "trucchi" e "ottimizzazione" contorta, le classi sono ben progettate, per citarne alcune. Come altri hanno già detto, lo stile di codifica è coerente, conciso e diretto .

Ad esempio, l'altro giorno, stavo dando un'occhiata al codice per TinyMCE per rispondere a una delle domande su Stack Overflow. È scritto in JavaScript, un linguaggio che ho usato raramente. Tuttavia, a causa dello stile di codifica e dei commenti inclusi, insieme alla strutturazione del codice stesso, era abbastanza comprensibile e sono stato in grado di navigare attraverso il codice in pochi minuti.

Un libro che mi ha aperto gli occhi per quanto riguarda la lettura del codice di un buon programmatore è Beautiful Code . Contiene molti articoli scritti da autori di vari progetti di programmazione in vari linguaggi di programmazione. Eppure, quando l'ho letto, ho potuto capire cosa stava scrivendo l'autore nel suo codice nonostante il fatto che non l'ho mai nemmeno programmato in quella particolare lingua.

Forse quello che dovremmo tenere a mente è che la programmazione riguarda anche la comunicazione, non solo al computer ma alle persone , quindi il codice di un buon programmatore è quasi come un libro ben scritto, che può comunicare al lettore le idee che vuole trasmettere .

• Facile da leggere
• facile da scrivere
• facile da mantenere

tutto il resto è filigrana

Un buon codice dovrebbe essere facilmente compreso.
Dovrebbe essere ben commentato.
Le parti difficili dovrebbero essere commentate ancora meglio.

Un buon codice è leggibile. Non avresti problemi a capire cosa sta facendo il codice alla prima lettura del codice scritto da un buon programmatore professionista.

Piuttosto che ripetere i grandi suggerimenti di tutti gli altri, suggerirò invece di leggere il libro Code Complete di Steve McConnell

Essenzialmente è un libro pieno di best practice di programmazione sia per funzionalità che per stile.

[Risposta puramente soggettiva]
Per me, un buon codice è una forma d'arte, proprio come un dipinto. Potrei andare oltre e dire che in realtà è un disegno che include caratteri, colori, "forma" o "struttura" di codice, e tutto questo è così leggibile / performante. La combinazione di leggibilità, struttura (cioè colonne, rientri, persino nomi di variabili della stessa lunghezza!), Colore (nomi di classi, nomi di variabili, commenti, ecc.) Fanno di ciò che mi piace vedere un'immagine "bella" che può rendimi molto orgoglioso o molto detestabile del mio codice.

(Come detto prima, risposta molto soggettiva. Scusa per il mio inglese.)

Secondo la raccomandazione di "Clean Code" di Bob Martin.

"Beautiful Code" è stato acclamato un paio di anni fa.

Vale la pena leggere uno qualsiasi dei libri di McConnell.

Forse anche "The Pragmatic Programmer" sarebbe stato utile.

%

Volevo solo aggiungere i miei 2 centesimi ... commenti nel tuo codice - e il tuo codice stesso, in generale - dovrebbe dire cosa fa il tuo codice, ora come lo fa. Una volta che hai il concetto di codice "client", che è codice che chiama altro codice (l'esempio più semplice è il codice che chiama un metodo), dovresti sempre preoccuparti di rendere il tuo codice comprensibile dal punto di vista del "client". Man mano che il tuo codice cresce, vedrai che questo è ... uh, buono.

Molte delle altre cose su un buon codice riguardano i salti mentali che farai (sicuramente, se presti attenzione) ... il 99% di loro ha a che fare con un po 'più di lavoro ora per risparmiarti un sacco di lavoro più tardi e riutilizzabilità. E anche facendo le cose bene: quasi sempre voglio correre nell'altro modo piuttosto che usare espressioni regolari, ma ogni volta che entro in esse, vedo perché tutti le usano in ogni singola lingua in cui lavoro (sono astrusi, ma lavoro e probabilmente non potrebbe essere migliore).

Per quanto riguarda se guardare i libri, direi decisamente non nella mia esperienza. Guarda le API, i framework e le convenzioni del codice e il codice di altre persone e usa il tuo istinto e cerca di capire perché le cose sono come sono e quali sono le implicazioni delle cose. La cosa che il codice nei libri non fa quasi mai è pianificare ciò che non è pianificato, che è lo scopo del controllo degli errori. Questo si ripaga solo quando qualcuno ti invia un'e-mail e dice "Ho ricevuto l'errore 321" invece di "ehi, l'app è guasta, yo".

Un buon codice è scritto pensando al futuro, sia dal punto di vista del programmatore che da quello dell'utente.

Questo è risposto abbastanza bene nel libro di Fowler, "Refactoring", è l'assenza di tutti gli "odori" che descrive in tutto il libro.

Non ho visto "ASP.NET professionale", ma sarei sorpreso se fosse meglio di OK. Vedi questa domanda per alcuni libri con un codice davvero buono. (Varia, ovviamente, ma la risposta accettata è difficile da battere.)

Questa sembra essere (dovrebbe essere) una FAQ. C'è un articolo ACMRecentemente su un codice stupendo. Sembra che ci sia molta enfasi sulla facilità di lettura / comprensione. Lo qualificherei con "facile da leggere / capire da esperti di dominio". I programmatori veramente bravi tendono a usare i migliori algoritmi (invece di algoritmi ingenui di facile comprensione O (n ^ 2)) per qualsiasi problema dato, che potrebbe essere difficile da seguire, se non hai familiarità con l'algoritmo, anche se il buono il programmatore fornisce un riferimento all'algoritmo.

Nessuno è perfetto tra cui buoni programmatori, ma il loro codice tendono a lottare per:

1. Correttezza ed efficienza con algoritmi collaudati (invece di hack ingenui e ad hoc)
2. Chiarezza (commento per intento con riferimento ad algoritmi non banali)
3. Completezza per coprire le basi (convenzione di codifica, versioning, documentazione, unit test ecc.)
4. Succinctness (DRY)
5. Robustezza (resiliente a input arbitrari e interruzioni delle richieste di modifica)

secondo la raccomandazione per il "codice pulito" di zio Bob. ma potresti voler dare un'occhiata a http://www.amazon.com/Implementation-Patterns-Addison-Wesley-Signature-Kent/dp/0321413091 perché penso che questo affronti un po 'meglio la tua domanda specifica. un buon codice dovrebbe saltare fuori dalla pagina e dirti cosa fa / come funziona.

Jeff Atwood ha scritto un bell'articolo su come i programmatori sono il primo riferimento per i dattilografi: http://www.codinghorror.com/blog/archives/001188.html

Quando sei un dattilografo devi sempre essere elegante nel tuo lavoro, avere una struttura e una "grammatica" adeguata è molto importante. Ora convertendolo in "programmazione" si otterrebbe lo stesso risultato.

Struttura

Commenti

Regioni

Sono un ingegnere del software, il che significa che durante la mia formazione mi sono imbattuto in molti linguaggi diversi ma la mia programmazione "si sente" sempre la stessa, come la mia scrittura su fekberg.wordpress.com, ho un modo "speciale" di digitare.

Ora programmando diverse applicazioni e in diversi linguaggi, come Java, C #, Assembler, C ++, C sono arrivato allo "standard" di scrittura che mi piace.

Vedo tutto come "scatole" o regioni e ogni regione ha le sue spiegazioni per i commenti. Una regione potrebbe essere "class Person" e all'interno di questa regione ho un paio di metodi per le proprietà, che potrei chiamare "metodi di accesso" o simili e ogni proprietà e regione ha i propri commenti esplicativi.

Questo è molto importante, vedo sempre il mio codice che faccio, come "parte di un'API", quando si crea una struttura API e l'eleganza è MOLTO importante.

Pensaci. Leggi anche il mio articolo in Communication issues when adapting outsourcingcui spiega in modo approssimativo quanto un codice cattivo possa entrare in conflitto, inserisci come preferisci: http://fekberg.wordpress.com/2008/12/14/communication-issues-when-adapting-outsourcing/

Un buon codice è facile da capire, facile da mantenere e facile da aggiungere. Idealmente, è anche il più efficiente possibile senza sacrificare altri indicatori.

Un ottimo codice per me è qualcosa di semplice da comprendere ma sofisticato. Le cose che ti fanno pensare, "wow, ovviamente, perché non la pensavo in quel modo?". Un codice davvero buono non è difficile da capire, risolve semplicemente il problema in questione in modo diretto (o ricorsivo, se è ancora più semplice).

Un buon codice è dove sai cosa fa il metodo dal nome. Il codice errato è dove devi capire cosa fa il codice, per dare un senso al nome.

Un buon codice è dove, se lo leggi, puoi capire cosa sta facendo in non molto più tempo di quello che serve per leggerlo. Il codice errato è dove finisci per guardarlo per anni cercando di capire se lo fa.

Un buon codice ha cose denominate in modo tale da rendere inutili commenti banali.

Un buon codice tende ad essere breve.

Un buon codice può essere riutilizzato per fare ciò che fa altrove, poiché non si basa su cose che non sono realmente correlate al suo scopo.

Un buon codice è di solito un insieme di semplici strumenti per svolgere lavori semplici (messi insieme in modi ben organizzati per svolgere lavori più sofisticati). Il codice errato tende ad essere enormi strumenti multiuso che sono facili da rompere e difficili da usare.

Il codice riflette le capacità e la mentalità di un programmatore. I buoni programmatori hanno sempre un occhio al futuro: come funzionerà il codice quando i requisiti o le circostanze non sono esattamente quelli che sono oggi. Quanto sarà scalabale? Quanto sarà conveniente quando non sono io a mantenere questo codice? Quanto sarà riutilizzabile il codice, in modo che qualcun altro che fa cose simili possa riutilizzare il codice e non scriverlo di nuovo. Cosa succede quando qualcun altro sta cercando di capire il codice che ho scritto.

Quando un programmatore ha quella mentalità, tutte le altre cose vanno a posto bene.

Nota: una base di codice viene elaborata da molti programmatori nel tempo e in genere non esiste una designazione specifica di base di codice per un programmatore. Quindi un buon codice riflette tutti gli standard dell'azienda e la qualità della loro forza lavoro.

(Uso "lui" sotto perché questa è la persona a cui aspiro ad essere, a volte con successo).

Credo che il nucleo della filosofia di un buon programmatore sia che pensa sempre "Sto programmando per me stesso in futuro quando avrò dimenticato tutto di questo compito, perché ci stavo lavorando, quali erano i rischi e anche come questo il codice avrebbe dovuto funzionare. "

In quanto tale, il suo codice deve:

1. Funziona (non importa quanto velocemente il codice arriva alla risposta sbagliata. Non c'è credito parziale nel mondo reale).
2. Spiega come sa che questo codice funziona. Questa è una combinazione di documentazione (javadoc è il mio strumento preferito), gestione delle eccezioni e codice di test. In un senso molto reale, credo che, riga per riga, il codice di test sia più prezioso del codice funzionale se non per altro motivo che spiega "questo codice funziona, questo è come dovrebbe essere usato, ed è per questo che dovrei ottenere pagato."
3. Sii mantenuto. Il codice morto è un incubo. La manutenzione del codice legacy è un lavoro ingrato ma deve essere eseguita (e ricorda, è "legacy" nel momento in cui lascia la tua scrivania).

D'altra parte, credo che il buon programmatore non dovrebbe mai fare queste cose:

1. Ossessionato dalla formattazione. Ci sono molti IDE, editor e graziose stampanti in grado di formattare il codice esattamente allo standard o alle preferenze personali che ritieni appropriate. Uso Netbeans, imposto le opzioni di formato una volta e premo alt-shift-F ogni tanto. Decidi come vuoi che appaia il codice, configura il tuo ambiente e lascia che lo strumento faccia il lavoro più difficile.
2. Ossessionati dalle convenzioni sui nomi a scapito della comunicazione umana. Se una convenzione di denominazione ti sta portando lungo la strada per denominare le tue classi "IElephantProviderSupportAbstractManagerSupport" anziché "Zookeeper", modifica lo standard prima di renderlo più difficile per la persona successiva.
3. Dimentica che lavora come una squadra con esseri umani reali.
4. Dimentica che la fonte principale degli errori di codifica è proprio ora la sua tastiera. Se c'è un errore o un errore, dovrebbe prima guardare a se stesso.
5. Dimentica quello che succede Qualsiasi lavoro che fa ora per rendere il suo codice più accessibile ai futuri lettori quasi certamente lo avvantaggerà direttamente (perché chi sarà la prima persona a cui verrà chiesto di guardare il suo codice? Lo è).

1. Funziona
2. Ha unit test che dimostrano che funziona

Il resto è la ciliegina ...

• Il codice migliore ha una certa eleganza che riconosci non appena lo vedi.
• Sembra realizzato, con cura e attenzione ai dettagli. È ovviamente prodotto con qualcuno con abilità e ha un'arte al riguardo - si potrebbe dire che sembra scolpito e levigato, piuttosto che ruvido e pronto.
• È coerente e si legge facilmente.
• È suddiviso in piccole funzioni altamente coese, ognuna delle quali fa una cosa e la fa bene.
• È minimamente accoppiato, il che significa che le dipendenze sono poche e strettamente controllate, di solito da ...
• Le funzioni e le classi dipendono dalle astrazioni piuttosto che dalle implementazioni.

Ironia della sorte il meglio al programmatore il meno indispensabile lui / lei diventa perché il codice prodotto è meglio gestibile da chiunque (come dichiarato dal generale consenso di Eran Galperin).

La mia esperienza dice che è vero anche il contrario. Il peggio il programmatore il più difficile mantenere la sua / il suo codice è, quindi più indispensabile lui / lei diventa, dal momento che nessun altra anima può capire gli enigmi prodotte.

Ho un buon esempio:

Leggi il codice sorgente di GWT (google web takingit), vedrai che ogni sciocco lo capisce (alcuni libri in inglese sono più difficili da leggere di questo codice).