Che dire di tutte quelle regole di codifica?

Falli coinvolgere nella risoluzione di un problema piuttosto che nelle regole di combattimento. Personalmente preferisco l'idea di "guide di stile", "standard di codifica" o qualcosa di simile, nella speranza che impedisca la reazione "regole = cattiva" del ginocchio.

Ma anche se lo fosse - tendo a pensare che le regole siano in vigore per una ragione, e il modo per far sì che le persone si diano da fare a turno sia farle capire che seguendo le linee guida, stanno aiutando a rendere codice più facile da leggere per tutti.

A volte la pressione dei pari è la soluzione migliore per questo.

Al mio lavoro usiamo tutte e tre le seguenti soluzioni:

1) Adotta un controllo di stile del codice come l'eccellente Checkstyle (per Java) o StyleCop (per C #). Questi sono strumenti facilmente configurabili che possono evidenziare automaticamente lo stile di codifica / le deviazioni delle regole. Offre a tutti una terza parte neutrale per determinare ciò che è e non è accettabile.

2) Adotta un modello di codice riformattato per il salvataggio automatico (ecco un esempio usando Eclipse) (e un altro per Visual Studio) che automaticamente formatta il tuo codice al salvataggio. Questo è ottimo per consentire a qualcuno di programmare come desiderano, ma avere tutto il codice formattato allo stesso modo su save / commit. Mi piace molto questo e il nostro codice non è mai stato più coerente.

3) recensioni del codice. Spero che lo farai comunque, ma una cosa che dovrebbero evidenziare è dove le regole e gli stili di codifica stanno rompendo le convenzioni.

Oltre a quanto sopra, è importante che tutti si trovino sulla stessa barca e abbiano concordato gli stili / le regole a cui stanno lavorando. Metti in chiaro che non otterrai un accordo da parte di tutti su tutto, ma chiedi l'impegno del team per mantenere fede a ciò che decide il team. Assicurati di rivedere di tanto in tanto gli stili / le regole scelte per tener conto dell'esperienza reale che li usa e il turn-over del team.

The real problem that comes from this is how to make those hard headed ones that don't like to use brackets in if statements, or use the same connections string everywhere in the code, or whatever,

Stanno diventando "difficili" non usando parentesi o questa è una richiesta "difficile"?

Scegli le tue battaglie. Dubito che questo è uno di quelli che vale la pena raccogliere. Non mi piacerebbe lavorare ovunque mi aspettassi vicino questo livello di dettaglio su "primo check-in codice". Questo è un indicatore a bandiera rossa che il team non comprende il refactoring.

OO 101 : "Refactor quando il prodotto fa quello che deve fare". Non prima.

È piuttosto difficile sedere a spalla di ogni singolo sviluppatore in team di grandi dimensioni, assicurandosi che mettano delle parentesi dove tu pensi che dovrebbero andare - fidati di me su quello;).

Se è qualcosa che ritieni davvero stia ostacolando il tuo sviluppo, allora avrai bisogno di un "gatekeeper". Ad esempio, non consentire alle persone di effettuare il check-in senza una revisione del codice. Chiedere all'architetto tecnico o al caposquadra di rivedere il codice e rifiutarlo finché non "correggono" lo stile del codice. Presto si stancheranno di questo e si adegueranno alle regole, probabilmente solo per il tempo in cui vengono controllate.

Naturalmente, alcune aziende tolgono completamente i privilegi di check-in dai programmatori junior. Quando finalmente imparano le regole di codifica delle aziende, ottengono il privilegio.

Penso che tu stia parlando di problemi di livelli molto diversi:

how to make those hard headed ones that don't like to use brackets in if statements,

Questo è principalmente un problema di stile / leggibilità, a meno che non ci sia un problema esplicito di precedenza degli operatori. Quest'ultimo non dovrebbe essere molto comune, ed è comunque testabile per unità, quindi facile da risolvere. Il primo può facilmente regredire in una guerra santa con poco da guadagnare, ma gravi conseguenze negative per il morale della squadra. Quindi, fai attenzione: applica regole provate e testate, che sono state accettate da almeno alcune squadre / comunità e hanno dimostrato di funzionare.

or use the same connections string everywhere in the code,

Se intendi le costanti magiche, si tratta in realtà di un problema di manutenzione (più potenzialmente di sicurezza) e in quanto tale, ogni sviluppatore esperto capirà e accetterà che si tratta di una brutta cosa.

or whatever, to use the coding rules without making them oppose the idea?

Non puoi costringere le persone a concordare con le regole di codifica: l'unica possibilità è di raggiungere una comprensione comune e il consenso dei membri del team attraverso discussioni e dibattiti (talvolta feroci) . Devi utilizzare argomenti logici e convincenti , mostrando il valore alla base di ciascuna regola e spiegando in che modo seguirla pagherà l'inconveniente di adeguare le abitudini radicate. D'altra parte, cerca di rendere la transizione il più semplice possibile , ad es. introducendo la formattazione automatica del codice al momento del check-in, secondo le regole accettate.

Tuttavia, a volte devi solo accettare che le persone hanno opinioni diverse , quindi le regole di codifica che tutti possono accettare saranno tolleranti per certi aspetti. Accettalo e concentrati sulle aree in cui puoi migliorare le cose con meno sforzo.

Coinvolgili nella definizione delle regole. Questo di solito aiuta a incoraggiare le persone a seguirli.

Questo è ciò che la revisione del codice è per. I revisori del codice non dovrebbero lasciare passare il codice che non soddisfa gli standard. Assicurati di non allentare le regole per le correzioni urgenti. Dovendo ripetere alcune volte sotto pressione per farlo fare, sistemare chi è riluttante a fare il proprio lavoro correttamente la prima volta.

La stessa stringa di connessione ovunque? La soluzione è quella di refactoring fino a quando non hai rimosso tutte le duplicazioni. I codificatori copia-incolla dovrebbero andare nella prigione del programmatore. (Non ridere! Steve Ballmer è il direttore.)

Ma il vero problema qui è il tuo verbo "make" . Non puoi fare in modo che i programmatori facciano qualsiasi cosa, e se lo fai, stai perdendo la loro caratteristica più preziosa: il profondo coinvolgimento intellettuale che deriva dal lavorare su qualcosa che ti interessa.

Il modo in cui lo risolverei:

1. Insistere sul fatto che il team abbia uno standard di codifica comune. Può essere lungo 5 righe, ma devono essere tutti d'accordo.
2. Ogni volta che si nota una discussione, insistono sul fatto di stabilirlo insieme e di inserirlo nello standard di codifica. Se noti persone che riformattano le cose avanti e indietro, trattale come argomento.
3. Ogni volta che viene concordato un articolo standard, verifica se c'è uno strumento che pulirà l'intera base di codici contemporaneamente.
4. Ogni paio di mesi, passa attraverso lo standard di codifica e vedi quali sono ancora veri e pertinenti. Lo standard documenta solo ciò che le persone stanno facendo. E non ha senso mantenere gli elementi nello standard che sono diventati ovvi.

La programmazione è uno sport di squadra o un'opera artistica collettiva. Ciò su cui le persone sono d'accordo non importa quasi quanto sono d'accordo, e sono bravi a venire a nuovi accordi, se necessario.