C'è qualche vantaggio nell'ossessione di rendere il codice "bello"?

A volte passo ridicole quantità di tempo (ore) in agonia per rendere il codice "bello". Intendo far sembrare le cose simmetriche. Scorrerò rapidamente un'intera classe per vedere se qualcosa salta fuori come non "carino" o "pulito".

Sto sprecando il mio tempo? C'è valore in questo tipo di comportamento? A volte la funzionalità o il design del codice non cambieranno nemmeno, lo ristrutturerò in modo che appaia più bello.

Sono solo totalmente un DOC o c'è qualche vantaggio nascosto in questo?

Usa un formatter automatico. Se stai davvero spendendo così tanto tempo a modificare manualmente il codice, sarei disposto a indovinare che non sei molto sfidato / annoiato, perché non c'è assolutamente alcun motivo. Ctrl + K, Cntrl + D in VS formatterà un intero documento. Puoi usare qualcosa come Style Cop se vuoi qualcosa di un po 'più pesante.

È bello essere orgogliosi del tuo codice, ma non quando si tratta di essere intelligenti (cercare la soluzione più efficiente. In questo caso, utilizzare uno strumento per automatizzare un processo noioso) e fare le cose (cos'altro potrebbe hai lavorato in quelle ore?).

Se non stai cambiando nulla che gli permetta di essere compreso meglio, allora sì, stai perdendo tempo.

Niente di nascosto, il bel codice è facile da leggere e da mantenere.

"Hours" sembra un po 'eccessivo, a meno che tu non abbia una base di codice enorme. Non tutto deve essere perfetto, deve solo essere buono

È una questione di giudizio; se passi ore, direi che stai esagerando. Tuttavia, ci sono cose che un essere umano può fare che un formatter automatico non può fare e cose che puoi fare per rendere il tuo codice più leggibile che sono difficili da catturare negli standard di codifica aziendale.

Ad esempio, quando dichiari le variabili in una classe, mi piace avere raggruppamenti logici - rende più semplice seguire la logica.

Il codice è generalmente considerato "scrivi una volta, leggi molti", quindi rendere piacevole l'esperienza di lettura è una buona abitudine - ma il layout secondo me è molto meno un problema rispetto a convenzioni di denominazione chiare, astrazioni pulite e firme dei metodi ben strutturate.

Ho visto un codice meravigliosamente formattato che ha causato gravi momenti WTF perché il processo di pensiero sottostante era imperfetto. Se hai ore da spendere, lo spenderei per la progettazione e il refactoring, piuttosto che per il layout ...

No, non sei totalmente un DOC. Il più grande complimento che abbia mai sentito come programmatore è stato: "Il tuo codice è così pulito che il mio fratellino è riuscito a capirlo."

Un giorno qualcuno dovrà supportare il tuo codice. Il codice pulito è molto più semplice da supportare. E un giorno potresti essere tu. Tra 6 mesi o un anno non ricorderai cosa hai fatto. Ma se è pulito e facile da leggere, tornerà rapidamente.

Detto questo, se il codice è spazzatura, non aiuta a essere piuttosto spazzatura. Ma se è strutturato bene e ha solo problemi di funzionalità, sarà molto più facile migliorare la funzionalità.

No - essere ossessionati dal rendere bello il codice non ha senso .

Ecco alcuni pezzi di saggezza che ho trovato utili:

Chiedi perché il codice deve essere ordinato.

Potresti o non stai sprecando il tuo tempo a seconda della definizione di pretty.

Il teorema fondamentale della formattazione afferma che un buon layout visivo mostra la struttura logica del programma. Far sembrare bello il codice vale qualcosa, ma vale meno che mostrare la struttura del codice. [pag 732, Code Complete 2nd Edition, Steve McConnell]

Se si utilizza il sistema di versioni simultanee per tenere traccia delle modifiche al codice - Non mescolare le modifiche alla formattazione del codice con le funzioni logiche / di aggiunta all'interno dello stesso commit.

Renderà più difficile individuare le modifiche e causerà inutili conflitti di unione se altri membri del team stanno modificando il file. Se è necessario apportare modifiche alla formattazione, verificare che gli altri membri del team non stiano lavorando su quel file. [Parafrasato, Pg 93, Controllo versione pragmatica con Subversion, 2a edizione]

Anche Martin Fowler parla di "indossare due cappelli" e di passare da uno all'altro durante il giorno. Un cappello per l'aggiunta di funzionalità, un cappello per il refactoring.

1. Prendi in considerazione l'aggiunta di una nuova funzionalità (Feature Hat)
2. Esamini il codice esistente per ottenere comprensione, riordinando mentre procedi. (Cappello refactoring)
3. Conferma le modifiche.
4. Aggiungi la funzionalità. (Feature Hat) e così via ....

[Parafrasato a pagina 57ish, Refactoring, Martin Fowler]

Quindi, non passare ore a cercare di preettificare l'intera base di codice. Basta settare abbastanza codice che è necessario per aggiungere la funzione successiva.

In breve ... lascia ogni pezzo di codice in uno stato migliore rispetto a quando sei arrivato.

Se si tratta semplicemente di formattazione, probabilmente è meglio investire un po 'di tempo nell'insegnare a una bella stampante come si desidera formattare il codice. Questo è un po 'costoso all'inizio, ma immagino che recupererai quel timer in 2-3 usi.

Se si tratta di refactoring reale, forse no. Il codice concettualmente pulito tende ad essere più semplice da modificare in futuro e avere "sempre pulito" riduce la tentazione di far passare qualcosa solo perché c'è altro codice puzzolente in giro.

Aiuta un po ', ma non vale la pena spendere molto tempo su di esso. Assicurati anche che i tuoi miglioramenti aggiungano anche scoping variabile, RAII, copia di gruppo / codice incollato ecc. Se fai tutto questo, diventa 1000x più facile quando devi capire cosa fa il codice dopo circa un anno.

Dovresti produrre codice pulito, ma non dovrebbero volerci ore.

Per C, c'è il programma gnu gnu-indent gnu-indent , in eclipse c'è almeno un codeformatter per Java, e immagino ci siano strumenti anche per la maggior parte degli altri linguaggi. Dovrebbero essere necessari pochi clic per rientrare correttamente in un file e pochi minuti, se ti piace violare le regole per scopi specifici, come faccio io per brevi dichiarazioni switch-case:

 switch (foo) {
      case a:  foo (a);             break; 
      case b:  foob ();             break;
      case c:  /* intent. empty */
      case d:  foocd ();            break; 
      default: allPrettyAligned (); break; 
 }

che è difficile da specificare.

Se pensi che qualcosa sembri pulito sfiorandolo, ti stai concentrando su qualcosa di superficiale che può essere automatizzato.

Leggi questo classico articolo su "Far sembrare sbagliato il codice sbagliato" e vedrai esattamente perché le persone pensano comunemente che il rientro (che può essere fatto automaticamente) sia banale:

http://www.joelonsoftware.com/articles/Wrong.html

In particolare questo elenco:

OK, finora ho menzionato tre livelli di successo come programmatore:

1 Non sai pulito da impuro.

2 Hai un'idea superficiale di pulizia, principalmente a livello di conformità alle convenzioni di codifica.

3 Inizi a annusare sottili accenni di impurità sotto la superficie e ti infastidiscono abbastanza da raggiungere e correggere il codice.

C'è un livello ancora più alto, tuttavia, che è ciò di cui voglio davvero parlare:

4 Architetti deliberatamente il tuo codice in modo tale che il tuo naso per impurità renda il tuo codice più probabile che sia corretto.

Questa è la vera arte: creare un codice solido inventando letteralmente convenzioni che fanno risaltare gli errori sullo schermo.

"Ore"? Bene, direi che la tua risposta è "e", non "o": sì, sei un DOC, ma ci sono alcuni vantaggi.

Probabilmente.

Rende il tuo codice più facile da leggere velocemente? Rende più facile sfogliare, capire cosa si ferma e inizia dove, trovare funzioni, variabili, ecc.? Rende più chiaro il modo in cui il codice funziona? Il processo di prettying-up ti costringe a rivisitare alcune decisioni di progettazione e pota il codice morto o elimina le soluzioni semi-cotte che alla fine hai abbandonato? Se è così, ha assolutamente valore.

D'altra parte, se hai trovato un modo perverso di attirare il tuo senso estetico senza realmente rendere il tuo codice più facile da lavorare, allora sì, è una dannata perdita di tempo.

Per quanto mi riguarda, tendo a cadere anch'io sul punto di disturbo ossessivo compulsivo, ma non mi fermerò. L'atto di fornire documentazione per una classe o una funzione mi costringe a pensare a come funziona davvero la cosa - la sto scrivendo in modo che qualcuno che non sia io possa capirla, dopo tutto. E se mi trovo a lanciare un mucchio di avvertimenti e avvertimenti e scuse per il motivo per cui il codice funziona nel modo in cui funziona, è un avvertimento piuttosto forte che ha bisogno di un altro giro di modifiche prima di dichiararlo finito.

Prima di tutto, non c'è niente di sbagliato nel rendere il tuo codice bello perché alla fine vuoi essere orgoglioso della tua creazione e la presentazione / formattazione del codice è parte di questo.

Tuttavia starei attento a non formattare eccessivamente il tuo codice per il bene dei tuoi colleghi o futuri sviluppatori. Abbastanza per te, potrebbe non essere carino per me. :)

Riconosci il problema (comportamento compulsivo) e il sintomo (formattazione ossessiva).

E la causa e la cura?

• Stai lavorando troppe ore?
• Sei frustrato, annoiato, ansioso?
• Qual è il tuo prossimo compito? È qualcosa che non vuoi fare?
• Quando hai fatto l'ultima vacanza? Promozione? Riconoscimento per un risultato?
• È un problema relativo al burn out?
• Sei in una marcia della morte?

A volte questi sintomi sono un segno che è tempo di apportare modifiche audaci o andare avanti.

Nonostante il suo titolo negativo, il libro di Yourdon ha molti suggerimenti utili e per molte organizzazioni sta facendo una descrizione abbastanza reale.

http://dev.co.ua/docs/Edward%20Yourdon%20-%20Death%20March.pdf

Sembri piuttosto perspicace e penso che potresti conoscere la risposta.

Ora, concediti il ​​permesso di agire su di esso.

Bovino Santo!
Non avete mai sentito parlare di indentazione?

è un'utilità di formattazione del codice che esiste da oltre 20 anni. Ha un mega-secchio di opzioni in modo che il tuo codice possa essere formattato in qualsiasi modo lo desideri, automaticamente.

ermm - ma funziona solo su C e alcuni ma non tutti su C ++ .... (wtf? perché GNU non lo aggiorna?)