Come hai trovato, perfezionato e mantenuto il tuo stile di codifica?

№1. # How did you define and find your coding style?

Attraverso esempi di codice prima nei libri, poi in testi e articoli MSDN, poi blog e altri siti web.

№2. How do you keep augmenting and improving it?

Tengo gli occhi aperti a tutti i suggerimenti che le persone fanno. Li provo, se lavorano per me, si attaccano. Sperimento anche di tanto in tanto, ciò che sembra migliorare le cose rimane con me.

№3. How do you maintain it? (From mental notes, keeping a document, using a tool like StyleCop etc.)

Mi piace ricordare il mio stile e applicarlo automaticamente ovunque.

Nota 1. Tenere gli occhi aperti e un orecchio aguzzo è estremamente importante per rimanere aggiornati. Anni fa ho appreso dagli altri che la notazione dell'Ungheria era d'obbligo, quindi l'ho seguita. Quando la comunità ha capito che non era così grande, sono cambiato con tutti.

Nota 2. Spesso non è così importante quali particolari elementi di stile si adottano, ma piuttosto che si mantiene il proprio stile coerente in tutti i codici. Lo stesso vale per una squadra. Scegli un po 'di stile, ma resta fedele ad esso.

Nota 3. Gli stili di codifica per lingue diverse possono variare. C ++ merita uno stile, Java l'altro. HTML e CSS hanno le loro caratteristiche richiedono di nuovo uno stile diverso.

Nota 4. Indipendentemente dallo stile scelto, comprendi e accetta che non funzionerà al 100%. A volte hai un codice che richiede uno stile diverso solo sul posto, diviso in più righe, diverso allineamento o qualsiasi altra cosa per mantenere quel particolare pezzo di codice più leggibile. Non spingere il tuo stile ovunque, concentrati sulla leggibilità del codice. Se è ovvio, lo stile non funziona in questa particolare posizione, fa un'eccezione.

Nota 5. Non seguire uno stile di codice per una religione. Gli strumenti che applicano uno stile di codice sono buoni, ma a volte possono farti arrabbiare. Ad esempio, ho disabilitato la formattazione automatica del codice di Visual Studio perché mi stava facendo impazzire. Se uno strumento diventa un ostacolo, aggiungi un'eccezione e non preoccuparti che il tuo codice non sia conforme al 100%. Non è così importante davvero e la perfezione non raggiungibile è comunque.

• Come hai definito e trovato il tuo stile di codifica?

Non penso ci sia stato un tempo in cui ho detto: "Ok, questo sarà il mio stile". Concentrati su un ambiente o una lingua specifici. Il tuo stile dovrebbe riflettere il modo in cui affronti un certo problema.

• Come continui ad aumentare e migliorandolo? Leggere i blog degli sviluppatori può essere utile per vedere a cosa stanno lavorando gli altri, cercando il software ampiamente utilizzato (se è così buono, magari potresti usare alcune delle loro soluzioni), ecc.
• Come lo mantieni? (Dal mentale note, mantenendo un documento, usando a strumento come StyleCop ecc.) Questa domanda ne aumenta un'altra: potresti perdere il tuo stile? Penso che sia una parte di te quindi non puoi, vero?

Ho lavorato in una squadra con un gioco a codice chiuso che ho amato e lo sviluppatore principale mi ha aiutato e migliorato le mie capacità dopo che gliel'ho chiesto anch'io.

Ha suggerito, e ho adottato lo stile di codifica di Zend Framework (http://framework.zend.com/manual/en/coding-standard.html)

Ho finito per adottare le caratteristiche di diversi stili, inclusi gli stili riflessi su MSDN. Quindi ho creato dei modelli in VS che forniscono i miei blocchi #region/#endregion e qualsiasi altra cosa che sia preferibile.

Continuo a studiare altri stili che incontro attraverso la ricerca e la lettura. Se penso che ci sia qualcosa che si distingue e potrebbe migliorare il mio stile di leggibilità, manutenzione o organizzazione, lo provo. Se è in corso una nuova regolazione dello stile, aggiornerò i modelli in VS o creeremo note mentali.

1. Lettura del codice sorgente DOOM.
2. Leggendo tutto il resto su cui potrei mettere le mani, scegliendo le parti che hanno funzionato.
3. Alcolismo funzionante.

Quando codifico da solo, mirano alla brevità; La programmazione spartana potrebbe essere completa, pazzia follia ... Ma probabilmente è la cosa più familiare al mio credo.

Quando codifico con gli altri, in particolare con la manutenzione del codice, cerco di essere un camaleonte - i miei cambiamenti dovrebbero migliorare ciò che modificano, senza guardare fuori posto.

How did you define and find your coding style?

Concentrandosi sulla semplicità e leggibilità (leggibilità! == comprensibilità, vedi Programmazione spartana )

How do you keep augmenting and improving it?

Esaminando gli altri e il mio codice (e persino gli stessi standard di codifica).

How do you maintain it? (From mental notes, keeping a document, using a tool like StyleCop etc.)

Uso dokuwiki , una brezza da configurare (nessun database), struttura gerarchica, controllo granulare (ACL out of the box), davvero bello, e beh, è un wiki, quindi chiunque può contribuire. Inoltre, i contributi / cambiamenti sono sempre sotto il consenso e giustificati, in base alla semplicità e alla leggibilità.

Questa è una specie di risposta strana, ma ho impiegato davvero molto tempo per iniziare effettivamente a programmare. Ho passato molto tempo a lavorare nelle 'arti' prima di considerarmi un programmatore.

Quando codifico, tendo a pensare in unità come la scrittura - paragrafi, frasi, ecc. Per questo motivo, sposterò il codice su più righe nel tentativo di renderlo leggibile come una storia / saggio / ecc. Mi infastidisce molto quando gli sviluppatori cercano di stipare il più possibile su una sola riga o in un piccolo spazio, perché non ottiene nulla oltre a far sì che lo scrittore si senta furbo e fastidioso per ogni futuro lettore.

Se ho bisogno di fare qualcosa di strano per motivi di efficienza, lo commenterò per spiegare perché è così.

Probabilmente non otterrò alcun risultato per questo, ma forse questo susciterà comunque qualche discussione.

Per quanto riguarda il lato tecnico, come il posizionamento di parentesi e simili, li tengo allineati perché il risultato è una maggiore leggibilità.

1. How did you define and find your coding style?

Vado per l'adozione di una guida di stile già sviluppata, ampiamente sviluppata e ampiamente accettata o divulgata da una grande azienda / progetto.

Lo faccio per numerose ragioni, ma principalmente perché tali guide di stile possono essere immediatamente adottate dagli sviluppatori. Una guida di stile vale solo quanto gli sviluppatori sono disposti a rispettarla.

Esempi di tali sono Python's PEP 8 , Guida allo stile di Android per Java , guida allo stile jQuery Core o guida in stile Python di Google .

2. How do you keep augmenting and improving it?

Il più grande argomento per tali guide di stile è che non sono stati inventati qui e non sono stati inventati da me. Ci sono voluti decine di sviluppatori, linee di codice intimidatorie e più tempo di quanto la tua azienda / squadra non sia mai disposta a investire nello sviluppo e nella gestione di una guida di stile.

Per quanto riguarda i miglioramenti, non c'è mai stata una guida di stile che risponda immediatamente a tutto che potresti aver bisogno di sapere. Ma, nella maggior parte dei casi, i miglioramenti che ho visto essere spinti in avanti sono solo una versione più dettagliata di ciò che la guida allo stile ha già aperto con il suo approccio alla scrittura del codice.

In questi casi, quando ti imbatti in un blocco di wierdness, dovresti incollarlo in un gist o in un altro strumento di condivisione dello snippet di codice appropriato con il supporto della sintassi del colore e discuterlo da qualche parte con altri sviluppatori. Il bello è che in questi casi non sei interessato a ciò che fa il codice, ma solo a come appare il codice, in modo da poter rimuovere quel blocco dal contesto e discutere come dovresti migliorare, confrontandolo con ciò che è già specificato in la guida allo stile come principale punto di partenza per le discussioni.

3. How do you maintain it?

Bene, il bello è che avrai già documenti esistenti che sono pubblicamente gestiti online.

Quando si tratta di formattazione del codice, è possibile anche fare il miglio supplementare e fornire al proprio team configurazioni di formattatore per il proprio editor preferito, che dovrebbe eliminare la crudezza e le congetture sul mantenimento delle apparenze di punta. In realtà, non lo definirei un miglio in più, ma parte integrante dello sviluppo - non c'è niente di peggio che fare una diff dove il 90% delle modifiche al codice era il check-in di qualcuno di un codice formattato / formattato correttamente perché qualcuno si era dimenticato di ripulire prima che commettessero una nuova enorme funzione.

Se fai parte di una squadra, devi sempre aggiungere lo standard del team. C'è molto da dire per usare un layout generico e non il tuo personale. Rende il tuo codice più facile da leggere e capire da altri che è essenziale.