La formattazione incoerente è un segno di un programmatore sciatto?

Hai ragione a sottolineare che gli utenti sono la cosa più importante, alla fine. Ma ecco il punto che penso tu abbia perso: altri sviluppatori sono utenti del tuo codice. È altrettanto importante ciò che vedono ciò che vedono gli utenti dell'applicazione.

Ora se era un compromesso, se il miglioramento del codice rendesse l'esperienza utente peggiore, allora dovrei dire di prestare attenzione al gruppo più grande (si spera che i tuoi utenti).

Ma non è un compromesso. Puoi raggiungere entrambi gli obiettivi contemporaneamente. Quindi fallo.

Come nota a margine, se sei l'unico sviluppatore che lavorerà a questo progetto (applicazioni usa e getta), allora non avrai un problema immediato. Ma non sarebbe meglio prendere l'abitudine di essere coerenti ora piuttosto che quando sei in un lavoro con una squadra?

Ci sono momenti in cui una squadra può prendere la decisione di permettere che il codice sia scritto in 2 (o anche più) modi diversi, ma di solito è sulla base di "cambieremo il nostro approccio per tutto il nuovo codice, cambieremo codice quando siamo in quella zona, ma non modificare il codice che non viene mai toccato fino a quando non rimane così poco che valga la pena di fare un progetto di esso. " Questi casi devono essere gestiti con molta attenzione.

EDIT : per rispondere alle tue modifiche: è solo peggio, nella mia mente. Non è un caso di scrittura maldestra perché l'IDE lo avrebbe corretto. Sembra che ci fosse un altro blocco di codice all'interno del se-if, che è stato cancellato insieme alla parentesi esterna. Questo è così facile da risolvere che non ci sono scuse per non averlo fatto.

Una volta che il rientro diventa fuori controllo, il codice diventa molto difficile da leggere e persino più difficile da eseguire il debug. Non penso affatto che tu stia facendo il pignolo.

Se c'è una certa coerenza, cerco di trascurarlo e andare avanti. Non c'è bisogno di essere un perfezionista. Ma se lo sviluppatore che ha scritto il codice è stato negligente, allora potrebbe non capire che altri sviluppatori dovranno leggere il loro codice, e se lo sviluppatore non capisce i concetti di leggibilità, allora questo mi dice qualcosa su questo sviluppatore che parla dei volumi:

Questa persona non sa come leggere il codice stesso!

In molte delle nostre carriere, non scriviamo necessariamente codice da zero. Invece della ripetizione, riutilizziamo blocchi di codice o consumiamo API scritte da altri sviluppatori, e questi costituiscono gli elementi costitutivi delle nostre applicazioni. Spesso, imparare a usare questi strumenti implica leggere la documentazione dell'API e leggere esempi di codice. Inoltre, comprendere i moduli in un progetto sviluppato internamente, dove potrebbero non esserci esempi di API o di codice, implica la capacità di leggere scrupolosamente e capire blocchi non familiari di codice legacy, la maggior parte dei quali probabilmente contiene problemi di formattazione e stile stesso.

Quando si assiste a un nuovo sviluppatore che scrive il proprio serializzatore JSON e gli chiede perché non usa Jackson o GSON, dice "Getta errori e non funziona. Non ha senso!"

Perché lo stava facendo?

Come uno sviluppatore scrive il suo codice ci dice molto sulle sue capacità. Considerando che nella maggior parte dei campi, un professionista di recente apprende dal lavorare con altri professionisti più esperti, vedere codice sciatto mi indica che la persona che lo ha scritto non ha avuto l'opportunità di imparare dagli altri, principalmente perché lui o lei non ha t provato.

Durante il tutoraggio di nuovi sviluppatori, lavoriamo su questi punti. Lo sviluppatore che ha scritto il suo sostituto Jackson ha ottenuto un nuovo rispetto per la leggibilità del codice quando abbiamo analizzato alcuni esempi di questo in azione.

Una volta che uno sviluppatore sperimenta questa prima mano, e comprende che il lavoro implica non solo scrivere codice ma anche leggerlo, il loro approccio cambia.

Joel Spolsky ha alcuni suggerimenti da Seth Gordon su su come ci si può avvicinare al codice di lettura .

Infine, se gli sviluppatori con cui stai lavorando non sono nuovi e sono in realtà i cosiddetti ingegneri senior, allora potresti prendere in considerazione la possibilità di trovare lavoro altrove. Questi ingegneri non rispettano te, il tuo tempo o l'organizzazione per cui lavorano, e non gliene importa se tu o qualcun altro devono ripulire il loro casino. Il codice formattato male, e non intendo solo alcuni caratteri di sottolineatura mancanti, è un segno di una patologia nell'organizzazione. O dice che sono inesperti, o semplicemente non se ne preoccupano.

Sì.

Prendendo un campione di 50 sviluppatori con cui ho lavorato, devo ancora incontrare uno sviluppatore che sia costantemente sciatto nella sua formattazione ma che abbia un output eccezionale in termini di correttezza del codice e che soddisfi tutti i requisiti funzionali e non funzionali requisiti coerenti ed efficaci.

La formattazione scadente è un segno di una mancanza di attenzione ai dettagli. Questa costante mancanza di dettagli, in tutti i casi nella mia esperienza personale, ha invariabilmente tradotto nella stessa mancanza di dettagli nella correttezza del codice.

In altre parole, non ho mai incontrato un grande sviluppatore (alta correttezza e manutenibilità) che è costantemente sciatto nella formattazione.

Sulla base di questa esperienza, utilizzo la sciatteria coerente, sistemica e ripetitiva di formattazione come indicatore negativo del calibro sviluppatore.

Penso che in qualche modo ti stai ponendo in parte la domanda sbagliata. Il codice è leggibile? Riesci a capire cosa dovrebbe fare a colpo d'occhio?

La formattazione del codice è qualcosa che consente alle persone che non hanno familiarità con il tuo codice di sentirsi a proprio agio. In un certo senso questa è una buona cosa, che potresti guardare il codice di qualcun altro e farlo sembrare simile ... comodo. Alcuni linguaggi (per esempio Python) richiedono un certo grado di formattazione per funzionare correttamente. In altri modi, la formattazione del codice è una distrazione in cui il linguaggio stesso non dipende realmente da esso. Ti interessa davvero se i tuoi metodi sono correttamente camel-cased, o se le tue variabili private iniziano con un trattino basso, o anche se i tuoi metodi pubblici e privati sono in una sorta di ordine specifico?

Questo mi riporta al problema della leggibilità. Il tuo compito è quello di codificare i requisiti e di comunicare ciò che hai fatto al prossimo sviluppatore che modificherà il codice dopo di te. Mantenere il codice in ordine, con una bella carcassa di cammello e una denominazione coerente può aiutare in una certa misura, ma direi che l'attenzione è nel dettaglio di ciò che si fa nel codice stesso. Mantenere i metodi corti, nominare tutti gli elementi del codice in modo descrittivo e rimuovere la duplicazione può fare una differenza maggiore se si è preoccupati se mettere o meno la parentesi graffa sulla riga successiva o se si ha un rientro coerente. Questi problemi di formattazione diventano più importanti quando il codice è lungo e difficile da analizzare rapidamente.

Il mio punto è che il tuo codice è probabilmente già nei guai se sei nella fase di preoccuparti di quanto attentamente sia formattato. Detto questo, se la formattazione ti infastidisce, ti costa molto poco per sistemare le cose mentre vai, a condizione che rientri nel campo di applicazione del lavoro che dovresti svolgere in quel momento.

Quindi, tutto questo accanimento o il segno di un codificatore scadente? Questo dipende in gran parte dal tuo punto di vista. Personalmente non la penso così. Potrebbe forse essere visto come un segno di pigrizia o scarsa attenzione ai dettagli, ma se il codice funziona e passa tutti i test, allora potresti chiederti quanto sia "sciatta" la codifica. D'altra parte, se qualcun altro trova difficile leggere il tuo codice, questo potrebbe essere un segnale che il tuo codice potrebbe essere difficile da mantenere, e questo di per sé sarebbe motivo di preoccupazione.

Se lavori in una squadra o se è probabile che il tuo codice venga mantenuto da altri, allora penso che sia meglio mantenere il tuo codice pulito, ordinato, leggibile e facile da capire. Le regole di formattazione e lo stile potrebbero dover essere discusse come un gruppo e alcune linee guida impostate, o codificate in uno strumento di controllo del codice (come StyleCop per C # per esempio). Se è il tuo progetto personale e non sarà mai curato da altri, allora il punto è discutibile, anche se direi che è meglio praticare buone tecniche di codifica pulita come un'abitudine piuttosto che qualcosa che fai occasionalmente.

Non posso fare a meno di pensare che la codifica riguarda solo i dettagli. Ogni dettaglio del nostro codice è importante - per correttezza, leggibilità, estensibilità, manutenibilità.

Anche se gli esempi forniti non sono disastrosi di per sé, per me parlano di una mancanza di attenzione ai dettagli che considererei preoccupante - in particolare in uno strumento come Visual Studio che offre così tanto aiuto - io uso Ctrl + K , Ctrl + D quasi come abitualmente come Ctrl + S

Lavoro con un programmatore che è altrettanto sciatto (e ignora palesemente i nostri standard di codifica con cose come lo spazio vuoto tra i metodi ei nomi in minuscolo dei metodi privati) e nel corso del tempo ci siamo resi conto che dobbiamo mantenere molto occhio attento al suo lavoro in quanto questa sciatteria si estende al suo design e ai suoi test, e abbiamo dovuto spendere un notevole sforzo "riordinando" dietro di lui.

Penso che sia un segnale che lo sviluppatore non stava usando gli strumenti a loro disposizione. Se stai usando uno strumento come IntelliJ Idea per Java, o uno qualsiasi degli altri IDE completi al momento, rendono così facile scrivere codice accurato che è altrettanto facile, o più semplice, farlo.

Il problema dell'essere rilassato nella tua formattazione è come è stato commentato, sul post originale altre persone che leggono il tuo codice sono probabilmente scettiche sulla qualità del resto del codice. Ancora più importante rende il codice più difficile da mantenere una volta diventato codice legacy.

Se stessi facendo una revisione del codice, sarei in grado di convivere con la spaziatura incoerente tra gli operatori, ma molto probabilmente fallirebbe la revisione a causa del rientro e della denominazione delle variabili incoerenti. Soprattutto quando una scorciatoia da tastiera lo formatterà per il tuo se stai usando un IDE. Penso che quando si lavora come parte di un team È importante che tutti utilizzino gli stessi strumenti e convenzioni per evitare il più possibile la mappatura mentale.

Suggerisco di provare a inserire un po 'di quel codice come parte di una domanda su Stack Overflow o come una revisione sulla beta di revisione del codice e vedere quali altri commenti si ottengono.

Alcune consistenze sono più importanti di altre.

Le incoerenze nell'indentazione possono essere il risultato dell'utilizzo di strumenti / piattaforme differenti. Stai rientrando con spazi o tab. Quanti spazi? Dove sono i punti di tabulazione.

Nei primi anni '90 le persone usavano le schede per sostituire 8 spazi e rientrare in 2 o 4 spazi. (In realtà, ho preferito 3). Quindi alcuni team hanno accettato di utilizzare solo le schede e quindi di impostare i punti di tabulazione ovunque desiderassero. Naturalmente, questo in seguito causò problemi poiché altri strumenti sostituivano automaticamente le schede con spazi o viceversa. Ora praticamente tutti usano gli spazi in modo che almeno tutti vedano sempre la stessa cosa.

Se vuoi irrigidire la formattazione, puoi usare Checkstyle per far rispettare le regole che desideri.

Personalmente, sono coerente con alcune cose in Java, come i nomi dei pacchetti sono tutti in minuscolo, i nomi delle classi iniziano con lettere maiuscole (e nient'altro) e altre pratiche in stile Java comuni. D'altra parte, non sono così coerente sul fatto di utilizzare o meno le parentesi in una dichiarazione if se non è necessario. Generalmente spazio attorno agli operatori aritmetici, ma non lo farò in alcuni casi, in particolare se è la differenza tra rendere la linea troppo lunga o meno.

Le differenze che vedo:

• Le incoerenze rendono il codice più difficile da leggere.
• Le incoerenze rendono più difficile ricordare o comprendere i punti importanti.
• Il costrutto porta a errori più facilmente trascurati.

Essere coerenti con la maiuscola rende molto facile capire a colpo d'occhio la differenza tra un nome di classe e una variabile. Essere incoerenti interrompe quello senza una buona ragione, e quindi è molto brutto.

Essere incoerenti sulla spaziatura attorno agli operatori aritmetici non è probabilmente un problema.

Non usare le parentesi graffe con un'istruzione if può essere pericoloso come se si aggiungesse una seconda istruzione alla clausola then senza aggiungere parentesi, quindi la seconda affermazione potrebbe sembrare che faccia parte della clausola then ma in realtà non lo è. Me non usare le parentesi graffe può, infatti, essere considerato sciatto. Non ho una difesa diversa da quella che salva una linea, rendendo il codice più compatto, che è debole, soprattutto perché metto sempre else su una nuova riga piuttosto che metterlo sulla stessa linea della parentesi di chiusura del "allora" clausola.

I programmatori variano nei loro stili. Alcuni dei programmatori più ingegnosi e creativi usano una rigorosa rigidità di stile come mezzo per liberare risorse mentali. (Una volta ho battuto un maestro di scacchi in una mostra di 60 persone facendolo dimettere semplicemente orientando i miei cavalieri in modo che si trovassero di fronte a lui. Voleva vederli di profilo.) Altri, come me, sentono che la rigidità a qualsiasi livello inibisce creatività e irritazione e regole che non sono dimostrabilmente importanti.

Come spesso accade, di solito è meglio trovare una sorta di mezzo felice.

La mia sensazione è che molte persone siano abbastanza coerenti nell'uso di spazi bianchi, underscore, ecc. per la stessa ragione per cui scrivono correttamente le parole, usano costantemente la punteggiatura, si allacciano le cinture, si lavano i denti partendo sempre dallo stesso lato , e così via. Quando fai una cosa regolarmente, ti abitui a farlo in un certo modo e lo fai senza pensarci troppo.

In questo momento, senza guardare il codice che ho scritto di recente, non posso dirti se di solito scrivo foo = bar; o foo=bar; , ma sono abbastanza sicuro che lo scrivo allo stesso modo ogni volta . (In effetti, posso dirti ora che faccio il primo: digitare il primo esempio è andato rapidamente, ma ho dovuto pensare di evitare di digitare spazi attorno a = nel secondo esempio.)

Se vedessi qualcuno scrivere codice che era molto incoerente nel modo in cui è stato formattato, non penserei necessariamente che fossero sciatti tanto quanto uno dei seguenti:

• erano inesperti e non avevano ancora sviluppato uno stile automatico;

• non avevano scritto molto codice di recente

• stavano avendo problemi con qualche altro aspetto del codice che porta a molte modifiche per tentativi ed errori

• il codice in questione è stato scritto qualche tempo fa ed era stato modificato da più persone nel corso della sua vita

Non è chiaro dalla tua domanda se stai parlando del tuo codice o di quello di qualcun altro. Se è il tuo e sei preoccupato di come si riflette su di te, allora è qualcosa su cui lavorare nelle prossime settimane. Dedica un po 'di tempo a capire come vuoi che il tuo codice appaia (in linea con gli standard di codifica aziendale), quindi presta maggiore attenzione mentre scrivi il codice nelle prossime settimane. Se ti stai davvero lamentando di uno dei tuoi colleghi, probabilmente è meglio non lasciarti disturbare e lasciare che il tuo manager lo indirizzi se si tratta di un problema per il team. Se sei amichevole con la persona in questione, potresti suggerire gentilmente di utilizzare uno strumento per la formattazione del codice. Molti IDE forniscono aiuto per la formattazione e ci sono un sacco di stampanti e formattatori di codice (ad esempio, Uncrustify) che possono aiutare.

Dovresti assolutamente parlargli di questo.

Per me, il codice formattato correttamente è molto importante. Mi permette di vedere rapidamente la struttura di un programma, trovare possibili errori, qualunque cosa. Quando c'è un codice che è solo una schermata di testo con una spaziatura molto piccola, è molto più difficile da leggere rispetto a quando è diviso in blocchi logici e alcuni spazi tra gli operatori, ecc.

Le sottovalutazioni nelle variabili private sono piuttosto importanti: è utile avere un modo per identificare rapidamente una variabile globale, quindi quando cerchi un problema, sai immediatamente che probabilmente non è contenuto in quel particolare metodo.

Come altri hanno già detto, se uno sviluppatore non è preoccupato di quanto sia leggibile il suo codice, c'è un problema. Probabilmente dovrà leggerlo lui stesso più tardi, e c'è una buona possibilità che non ricorderà ciò che quel pezzo di codice fa a memoria. Forse non ha ancora lavorato su un grande progetto, dove questo è un problema più grande che nei piccoli progetti.

Ricordo che persone nelle classi di programmazione mi chiedevano aiuto, e di tanto in tanto dovevo dire loro di formattare il loro codice prima che potessi anche cominciare a guardare a cosa non andava. È incredibile vedere quante persone pensano che l'indentazione e la corretta denominazione delle variabili non siano importanti.

Immagina un falegname che costruisce un grande pezzo di legno, lasciando tutti gli strumenti sparsi su tutto il banco di lavoro, in modo disordinato, mentre costruisce questa grande opera d'arte in legno. Ora immagina che il falegname si ammali e un falegname arrivi per finire il pezzo di legno. Quando vede tutto il casino intorno a lui, perde tempo e pazienza per organizzare tutto ciò che lo circonda in modo che possa iniziare a finire il pezzo nel modo che conosce meglio. Alla fine, il pezzo di legno è bello, bello, brillante e il cliente lo compra.

Ora cambia il carpentiere da uno sviluppatore di software.

Credo che la lezione importante qui sia la soddisfazione del cliente con il prodotto software, ma anche come importante, è come gli sviluppatori lavorano insieme e usano correttamente gli strumenti disponibili che hanno e per essere organizzati in modo che tutti possano lavorare in modo veloce e produttivo con tutti gli altri funzionano.

Penso che ogni sviluppatore dovrebbe essere perfezionista, amare ciò che sta facendo in modo che lui / lei possa divertirsi a risolvere i problemi dei clienti e lasciare un banco di lavoro pulito (indentazione corretta, uso corretto dei nomi delle variabili, documentazione eccellente, ecc. .) per gli altri di utilizzare e migliorare il suo / il suo lavoro.

Non penso che la consistenza sia davvero il problema: è se il codice letto da un altro programmatore trasmetta esattamente la funzione del codice. Dipende dal contesto.

L'idea che le parentesi graffe corrispondenti debbano essere allineate o che il nome di una variabile dovrebbe essere indicativo del suo scopo è piuttosto universale. Quindi qualcuno che digita le parentesi che non si allineano o che fornisce nomi di variabili che sono contrari al loro scopo sta trasmettendo informazioni false. Ciò è negativo: anche se il codice potrebbe funzionare, potrebbe anche essere il risultato di errori bilanciati. È fragile e instabile.

D'altra parte, come le variabili sono maiuscole e ciò che significa è molto più vario. Dipende dalle convenzioni del linguaggio, dalla piattaforma, dall'ambiente di sviluppo e soprattutto dalle convenzioni del team di programmazione. Se non ci sono convenzioni coerenti, se non è stato scritto nulla per dire "questo è come dovrebbe essere fatto", allora non c'è motivo di aspettarsi un codice coerente. In altre parole, se una particolare pratica stilistica non ha significato in un dato contesto, allora l'inconsistenza non ha alcun significato.

Dei quattro esempi originali, direi che le variazioni in 1, 2 e 4 sono significative solo se a quegli elementi sono stati dati significati ben stabiliti in primo luogo. Solo # 3 ha un significato abbastanza universale e anche allora sarei critico solo se l'allineamento fosse abbastanza lontano da essere veramente fuorviante.

Si potrebbe sostenere che un buon programmatore dovrebbe avere uno stile autoconsistente anche in assenza di uno stile imposto dall'esterno, ma penso che sia un falso presupposto. Un buon programmatore dovrebbe essere in grado di adattarsi alle regole che sono state date e quelle regole cambieranno man mano che passano da un progetto all'altro. Quindi, se c'è un'incongruenza nell'assenza di regole, è l'assenza di regole e non l'incoerenza che è responsabile di eventuali problemi di leggibilità.

Sono in ritardo alla domanda, ma merita questo: il codice del computer è l'espressione dell'intenzione dello sviluppatore. Se lo sviluppatore non sta esprimendo o non può esprimere il suo intento sia al compilatore che al prossimo umano di mantenere il suo codice, allora non sta facendo il suo lavoro.

Se il codice "sciatta" rende l'intento dello sviluppatore meno chiaro o dà addirittura l'impressione di intenti diversi, allora è un problema. In alcuni casi sarà un problema per il compilatore, in altri casi sarà un problema per il manutentore. Ma è ancora un problema, in quanto non abbiamo bisogno che il manutentore "risolva" l'intento e poi introduca bug perché la "correzione" era sbagliata.

In parole semplici:

Un software davvero eccezionale può essere costruito solo su solide basi. Il codice pulito e coerente è una di quelle fondamenta.

La continua astrazione della complessità è ciò che consente ai programmatori di fare cose sempre più grandi.

In che modo puoi fare cose sempre più grandi se devi far fronte a tutto il tempo per codificare l'incoerenza?

L'incoerenza del codice aggiunge la sua complessità ai problemi del dominio.

Inoltre, essere coerenti richiede meno sforzi complessivi rispetto al contrario.

Any fool can write code that a computer can understand. Good programmers write code that humans can understand. (M. Fowler)

Ci sono molte ragioni per cui le cose di cui ti lamenti possono accadere a uno sviluppatore perfetto.

Some example of inconsistencies might be:

Sometimes naming private variables with _ and sometimes not

Questo è un po 'fastidioso. L'ho già fatto prima. Forse sono in uno stato intermedio di vedere se postfix _ è qualcosa che vogliono usare.

Sometimes having varying indentations within code blocks

Not aligning braces up i.e. same column if using start using new line style

Ciascuno di questi può essere attribuito al codificatore utilizzando un editor che fa le cose per loro. A volte quegli editor fanno qualcosa di strano e non si sa mai.

Potrebbe anche essere stato modificato in più editor e / o da più persone. Inoltre, forse è il TUO editor che sta visualizzando il codice sbagliato.

Spacing not always consistent around operators i.e. p=>p+1, p+=1 vs other times p =>p+1 or p => p + 1 etc

Errore di battitura, diversi requisiti di formattazione per condizioni diverse, ecc ...

Non sudare le piccole cose. Metti in risalto queste cose, ma non sono un segno importante di uno sviluppatore cattivo, no.

Un mio amico programmatore ha la dislessia. Non ha difficoltà con il pensiero logico, o con la scrittura di un codice funzionale, elegante, ben collaudato, tutto ciò che si può ragionevolmente aspettarsi da uno sviluppatore decente. Ma difficilmente può scrivere per salvargli la vita, e semplicemente non si accorge di incongruenze nell'ortografia e nella formattazione tanto quanto le altre persone, perché la sua mente è più attenta ad altri tipi di dettagli. p>

Questa è la parte più remota dello spettro, ma devi capire che mentre gli sviluppatori devono essere orientati ai dettagli, non tutti gli sviluppatori sono orientati ai dettagli allo stesso modo , specialmente quando si tratta di aspetti di il codice che non influisce sul suo funzionamento attuale.

In conclusione: se vuoi il codice standard, esegui autoformat e passa a cose più importanti.

Suppongo che sia all'altezza degli standard dell'organizzazione. Se non hai alcune linee guida per la formattazione, proverei a metterlo all'ordine del giorno se fossi in te.  Una volta che uno standard è stato concordato, puoi utilizzare la funzione di formattazione del tuo editor preferito per assicurarti che tutti utilizzino lo stesso standard. (può persino utilizzare ciò che gli piace prima di inviarlo a monte se applica lo strumento di formattazione prima di inviare il codice al server di controllo sorgente)

Riguardo alle sue preoccupazioni riguardo ai suoi standard se il suo codice non è formattato correttamente: penso che potrebbe essere un indicatore di quanta attenzione presti ai dettagli. Se pensi che questo sia il caso, potrebbe essere qualcosa da discutere, ma questo può anche essere colto nelle revisioni del codice e può ottenere un feedback significativo da cui può imparare. agitarsi sullo stile del codice è solo come mettere la forma al di sopra di me. Se scrive codice sciatto, probabilmente verrà visualizzato anche nelle sue metriche di qualità, quindi lo stile del codice da solo non vale davvero la pena, ci sono strumenti per questo.