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

Usa un auto-formattatore. Se passi davvero tanto tempo a modificare manualmente il codice, sarei disposto a indovinare che non sei molto sfidato / annoiato, perché non c'è assolutamente alcun motivo per farlo. 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 è a spese di essere intelligenti (cercare la soluzione più efficiente.) In questo caso, usare uno strumento per automatizzare un noioso processo) e fare le cose (cos'altro avresti potuto lavorare durante quelle ore?).

Se non stai modificando nulla che permetta di comprenderlo meglio, allora sì, stai sprecando il tuo tempo.

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

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

È una questione di giudizio; se passi ore, direi che stai andando oltre le righe. Tuttavia, ci sono cose che un umano può fare che un auto-formattatore non può fare e cose che puoi fare per rendere il tuo codice più leggibile che è difficile da catturare negli standard di codifica aziendale.

Ad esempio, quando dichiaro le variabili in una classe, mi piace avere raggruppamenti logici: semplifica il seguire la logica.

Il codice di solito è considerato "scrivi una volta, leggi molti", quindi rendere piacevole l'esperienza di lettura è una buona abitudine - ma il layout a mio parere è molto meno un problema di convenzioni di denominazione chiare, astrazioni pulite e un metodo ben strutturato firme.

Ho visto codice meravigliosamente formattato che ha causato gravi momenti WTF perché il processo di pensiero sottostante era difettoso. Se hai ore da spendere, lo spenderei in design e refactoring, piuttosto che nel layout ....

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

Un giorno qualcuno dovrà supportare il tuo codice. Il codice pulito è molto più facile 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 una bella spazzatura. Ma se è strutturato bene e ha solo problemi di funzionalità, allora sarà molto più facile migliorare la funzionalità.

No: essere ossessionati dal fatto che il codice sembra bello è manca il punto .

Ecco alcuni elementi di saggezza che ho trovato utili:

Chiedi Perché il codice deve essere ordinato.

Potresti o meno sprecare il tuo tempo a seconda della tua definizione di carina.

The Fundamental Theorem of Formatting says that good visual layout shows the logical structure of the programme. Making the code look pretty is worth something, but it's worth less than showing the code's structure. [pg 732, Code Complete 2nd Edition, Steve McConnell]

Se usi Sistema di versioni concorrenti per tenere traccia delle modifiche nel codice - Non mescolare le modifiche alla formattazione del codice con Logica / Aggiunta Caratteristiche Modifiche all'interno dello stesso commit.

It'll make changes harder to spot and will cause unnecessary merge conflicts if other team members are editing the file. If you must make formatting changes, check that other team members are not working on that file. [Paraphrased, Pg 93, Pragmatic Version Control Using Subversion , 2nd Edition]

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

1. You consider adding a new feature (Feature Hat)
2. You peruse the existing code to gain understanding, tidying as you go. (Refactoring Hat)
3. Commit the Changes.
4. Add the feature. (Feature Hat) and so on....

[Paraphrased pg 57ish, Refactoring, Martin Fowler]

Quindi, non passare ore a cercare di migliorare l'intero codice base. Basta creare un numero sufficiente di codice necessario per aggiungere la prossima funzione.

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

Se si tratta di una pura formattazione, probabilmente è meglio investire un po 'di tempo nell'insegnare a una stampante carina come si desidera che il codice sia formattato. È un po 'costoso, ma immagino che recupererai quel timer in 2-3 utilizzi.

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

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

Dovresti produrre codice pulito, ma non dovrebbe richiedere ore.

Per C, c'è il programma gnu-indent gnu-indent , in eclissi, c'è almeno un codeformatter per Java, e immagino ci siano strumenti anche per la maggior parte degli altri linguaggi. Dovrebbero bastare pochi clic per indentare un file in modo corretto e alcuni minuti, se ti piace violare le regole per scopi specifici, come faccio per le brevi dichiarazioni caso-macchina:

 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 sembra pulito sfiorandolo, ti stai concentrando su qualcosa di superficiale che può essere automatizzato.

Leggi questo classico articolo su "Rendere sbagliato il codice sbagliato" e vedrai esattamente perché la gente pensa che il rientro (che può essere fatto automaticamente) sia banale:

link

In particolare questo elenco:

OK, so far I’ve mentioned three levels of achievement as a programmer:

1 . You don’t know clean from unclean.

2 . You have a superficial idea of cleanliness, mostly at the level of conformance to coding conventions.

3 . You start to smell subtle hints of uncleanliness beneath the surface and they bug you enough to reach out and fix the code.

There’s an even higher level, though, which is what I really want to talk about:

4 . You deliberately architect your code in such a way that your nose for uncleanliness makes your code more likely to be correct.

This is the real art: making robust code by literally inventing conventions that make errors stand out on the screen.

"Ore"? Bene, direi che la tua risposta è "e", non "o": sì, sei un OCD, ma c'è qualche vantaggio.

Probabilmente.

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

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

Per quanto mi riguarda, tendo a cadere anch'io sul lato OCD di questo - ma non mi fermerò. L'atto di fornire documentazione per una classe o una funzione mi costringe a pensare a come la cosa funziona davvero - la sto scrivendo in modo che qualcuno che non sono io possa capirlo, dopotutto. E se mi trovo a lanciare un sacco di avvertimenti e scuse per il perché il codice funziona come fa, questo è un avvertimento abbastanza strong che ha bisogno di un altro round di modifiche prima di dichiarare che è finito.

Prima di tutto nulla di sbagliato nel rendere il tuo codice un aspetto gradevole, perché alla fine vuoi essere orgoglioso della tua creazione e la presentazione / formattazione del codice è una parte di ciò.

Tuttavia, farei attenzione a non sovrascrivere il codice per i tuoi colleghi o futuri sviluppatori. Abbastanza carina per te potrebbe non essere carina con me. :)

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

E la causa e la cura?

• Lavori troppe ore?
• Sei frustrato, annoiato, ansioso?
• Qual è il tuo prossimo compito? È qualcosa che non vuoi fare?
• Quando hai trascorso l'ultima vacanza? Promozione? Riconoscimento per un risultato?
• È un problema correlato alla masterizzazione?
• Sei in una Marcia della Morte?

A volte questi sintomi sono un segno, è ora di apportare modifiche in grassetto o andare avanti.

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

link

Sembri abbastanza perspicace e penso che potresti conoscere la risposta.

Ora, concediti il permesso di agire su di esso.

Santo Bovino!
Voi ragazzi 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 su tutti i C ++ .... (wtf? perché GNU non lo aggiorna?)