Di recente, sono passato da diversi progetti e ambienti di sviluppo. Le aspettative per lo stile di codifica in ciascuno sono diverse.
Ora, la mia domanda è in tre parti, la prima, solo per curiosità:
Risposte:
№1. # Come hai definito e trovato il tuo stile di programmazione?
Attraverso esempi di codice prima nei libri, poi nei testi e negli articoli MSDN, poi nei blog e in altri siti web.
№2. Come continui ad aumentare e migliorarlo?
Tengo gli occhi aperti su tutti i suggerimenti che le persone fanno. Li provo, se funzionano per me, si attaccano. Di tanto in tanto faccio esperimenti, ciò che sembra migliorare le cose rimane con me.
№3. Come lo mantieni? (Da note mentali, conservazione di un documento, utilizzo di uno strumento come StyleCop ecc.)
Ricordo il mio stile e lo applico automaticamente ovunque.
Nota 1. Tenere gli occhi aperti e le orecchie ben affilate è estremamente importante per rimanere aggiornati. Anni fa ho appreso da altri che la notazione ungherese era un must, quindi l'ho seguita. Quando la comunità ha capito che non era così bello, sono cambiato con tutti.
Nota 2. Spesso non è così importante quali elementi di stile particolari si adottano, ma piuttosto che si mantenga coerente lo stile in tutti i codici. Lo stesso vale per una squadra. Scegli un certo stile ma poi atteniti ad esso.
Nota 3. Gli stili di codifica per lingue diverse possono variare. Il C ++ merita uno stile, Java l'altro. HTML e CSS hanno le loro caratteristiche che richiedono di nuovo uno stile diverso.
Nota 4. Qualunque stile tu scelga, capisci e accetta che non funzionerà al 100%. A volte hai del codice che richiede uno stile diverso appena sul posto, diviso in più righe, allineamento diverso 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 questo particolare posto, fai un'eccezione.
Nota 5. Non fare seguire uno stile di codice a 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.
Non credo ci sia stato un momento 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 determinato problema.
Ho lavorato in una squadra con un gioco a codice chiuso che amavo e lo sviluppatore principale mi ha seguito e mi ha aiutato a migliorare le mie abilità dopo che glielo avevo chiesto.
Mi 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 caratteristiche di stili diversi, inclusi stili riflessi su MSDN. Ho quindi impostato modelli in VS che forniscono i miei #region/#endregionblocchi e qualsiasi altra cosa 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 possa migliorare il mio stile in leggibilità, manutenzione o organizzazione, lo provo. Se è necessario un nuovo adattamento di stile, aggiornerò i modelli in VS o prenderò appunti mentali.
Quando scrivo da solo, cerco la brevità; La programmazione spartana può essere completa, folle follia ... Ma è probabilmente la cosa familiare più vicina al mio credo.
Quando codifico con altri, specialmente con i codici di manutenzione, ho l'obiettivo di essere un camaleonte: le mie modifiche dovrebbero migliorare ciò che modificano, senza guardare fuori posto.
Come hai definito e trovato il tuo stile di programmazione?
Concentrandosi su semplicità e leggibilità (leggibilità! == comprensibilità, vedi Programmazione spartana )
Come continui ad aumentare e migliorarlo?
Esaminando gli altri e il mio codice (e persino gli stessi standard di codifica).
Come lo mantieni? (Da note mentali, conservazione di un documento, utilizzo di uno strumento come StyleCop ecc.)
Uso dokuwiki , un gioco da ragazzi per l'installazione (senza database), struttura gerarchica, controllo granulare (ACL out of the box), aspetto davvero bello, e beh, è un wiki, quindi chiunque può contribuire. Inoltre, i contributi / i cambiamenti sono sempre sotto consenso e giustificati, basati su semplicità e leggibilità.
Questa è una specie di risposta strana, ma ho impiegato davvero molto tempo a prendere effettivamente la programmazione. Ho trascorso molto tempo a lavorare in "the arts" prima di considerarmi un programmatore.
Quando codifico, tendo a pensare in unità come la scrittura - paragrafi, frasi, ecc. Per questo motivo, diffonderò il codice su più righe nel tentativo di renderlo leggibile come una storia / saggio / ecc. Mi arrabbio molto quando gli sviluppatori cercano di stipare il più possibile su una riga o in un piccolo spazio, perché non realizza nulla oltre a far sentire lo scrittore intelligente e fastidioso per i futuri lettori.
Se ho bisogno di fare qualcosa di strano per motivi di efficienza, lo commenterò per spiegare perché è così.
Probabilmente non otterrò alcun voto per questo, ma forse questo susciterà comunque qualche discussione.
Per quanto riguarda il lato tecnico, come il posizionamento delle parentesi e simili, le tengo allineate 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 che è ampiamente sviluppata e ampiamente accettata o resa popolare da una grande azienda / progetto.
Lo faccio per numerosi motivi, 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 questo sono PEP 8 di Python , la guida di stile Android per Java , la guida di stile jQuery Core o la guida di stile Python di Google .
2. How do you keep augmenting and improving it?
L'argomento principale per tali guide di stile è che non sono state inventate qui e non sono state inventate da me. Ci sono voluti decine di sviluppatori, linee di codice minacciose e più tempo di quanto la tua azienda / squadra sarebbe mai stata disposta a investire nello sviluppo e nel mantenimento di una guida di stile.
Per quanto riguarda i miglioramenti, non c'è mai stata una guida di stile che risponda immediatamente a tutto ciò che potresti aver bisogno di sapere. Ma, nella maggior parte dei casi, i miglioramenti che ho visto essere spinti in avanti erano solo una versione più dettagliata di ciò che la guida di stile aveva già messo a punto con il suo approccio alla scrittura del codice.
In questi casi, quando ti imbatti in un blocco di stranezze, dovresti incollarlo in un riassunto o in qualche altro strumento di condivisione dello snippet di codice appropriato con supporto per la sintassi del colore e discuterne da qualche parte con altri sviluppatori. La cosa grandiosa è che in questi casi non sei interessato a ciò che fa il codice, ma solo a come appare il codice, quindi puoi rimuovere quel blocco dal contesto e discutere come dovresti procedere per migliorarlo, confrontandolo con ciò che è già specificato in la guida di stile come principale punto di partenza per le discussioni.
3. How do you maintain it?
Bene, la cosa fantastica è che avrai già documenti esistenti gestiti pubblicamente online.
Quando si tratta di formattazione del codice, puoi anche fare il possibile e fornire al tuo team le configurazioni del formattatore per il suo editor preferito, che dovrebbe eliminare il rozzo e le congetture per mantenere le apparenze al top. In realtà, non lo definirei uscire di un miglio in più, ma parte integrante dello sviluppo - non c'è niente di peggio che fare un diff dove il 90% delle modifiche al codice è stato il check-in di qualcuno di codice formattato / disegnato correttamente perché qualcuno ha dimenticato di ripulire prima di impegnarsi in una nuova enorme funzionalità.
Se fai parte di una squadra, dovresti sempre aderire allo standard della squadra. C'è molto da dire su un layout generico e non su quello personale. Rende il tuo codice più facile da leggere e capire dagli altri, il che è essenziale.