Esiste un modo per supportare diversi stili di codifica in un team di sviluppo

Il problema: due sviluppatori => tre opinioni sull'indentazione, parentesi graffe su una nuova linea o no, ecc.

Di solito lavoriamo con tre o quattro persone sui nostri progetti e ognuno di essi ha il suo stile di codice. Lo so, la soluzione comune è concordare uno stile di codice, tutti devono usarlo, ma non voglio forzare i programmatori creativi in ​​un abito che non si adatta a loro.

Quindi la domanda è: c'è un modo per consentire a ciascun programmatore di vivere il proprio stile, ma avere una base di codice comune all'interno del repository? Penso a qualche plugin git / svn / qualunque, che cambia tra stile personale e comune al momento del checkout e del commit. Mi sembra che la parte difficile di questo approccio sia quella di supportare le differenze corrette tra le versioni di un file

No, dovrai creare uno standard. Se hai un membro del team B che modifica (o con uno strumento IDE automatico o manualmente) un intero mucchio di codice del membro del team A scritto, che verrà eseguito il commit e verrà mostrato come un cambiamento.

Questo è qualcosa che quasi tutti i team affrontano e gli standard sono "forzati" proprio per questo motivo. Ti suggerirei di seguire gli standard delle autorità linguistiche come base e di adottarli per adattarli alla tua squadra.

Avere uno stile di codifica coerente aiuterà anche nella manutenibilità del progetto e ridurrà la barriera all'ingresso per le nuove persone che lavorano sul codice.

No, dovrai definire uno standard di codifica (preferibilmente uno già esistente) e far aderire i tuoi sviluppatori. Essere un programmatore professionista significa che sei in grado di adattarti a qualsiasi standard di codifica utilizzato nel progetto a cui stai lavorando.

SÌ, può funzionare fintanto che gli stili sono tutti sensati e le persone non vanno in giro a cambiare il codice di altre persone per abbinare le loro preferenze e / o mescolare gli stili in un singolo file di codice.
Non è l'ideale, ma non è diverso dall'ereditare il vecchio codice creato in uno "standard" diverso dal tuo e dal doverlo integrare con la tua base di codice.
Quindi, se devi farlo, alcune linee guida:

• nessuna modifica di codice di diverso stile in base alle proprie preferenze, costa tempo e introduce bug
• rimanere coerenti all'interno di ogni singolo file. Quindi, se lo stile A è stato inizialmente utilizzato per scriverlo, tutti lo useranno durante la modifica
• crea uno standard comune per la tua interfaccia pubblica, quindi per tutto ciò che è esposto all'esterno (e sì, altri sottocomponenti di un sistema sono l'esterno).

La risposta breve è No.

Mentre le opinioni devono essere valutate nel lavoro, specialmente in un lavoro basato sulla conoscenza come lo sviluppo del software, gli sviluppatori devono rendersi conto che un'opinione è solo un'opinione e che sono lì per scrivere software non discutere su quale standard di rientro sia il migliore.

L'obiettivo di un documento sugli standard dovrebbe essere quello di applicare / suggerire una serie di standard / convenzioni di codifica comuni che si rivolgono

1. Elementi del layout come tabulazione, rientro, uso di {, (,
2. Nome variabile, oggetto e funzione, ad esempio CamelCase, notazione ungherese
3. Eccezione Gestione di come / quando / dove deve essere eseguita
4. Commenti sul codice. Fai sempre riferimento a un documento di progettazione, un numero di bug ecc

I documenti sugli standard aiutano a garantire che il codice sia di facile lettura, manutenzione e coerenza nelle convenzioni.

Ciò ha un valore inestimabile quando si rivede il codice prima di effettuare il check-in, si esegue il debug di qualcun altro o si modifica il codice diversi anni dopo che lo sviluppatore originale ha lasciato l'azienda.

Normalmente durante la creazione di un documento sugli standard di codifica rivedo gli standard di settore per il linguaggio che sto usando (C, C #, SQL), uso gli standard più appropriati, faccio circolare gli sviluppatori più esperti / influenti per i commenti, incorporano i commenti dove appropriato e poi rilasciare il documento.

In teoria è possibile riformattare automaticamente il codice prima che venga eseguito il commit nel sistema di controllo della versione.

Tuttavia , c'è un grosso problema: gli strumenti di formattazione automatica del codice non sono affidabili al 100%. Pertanto, potresti effettivamente introdurre problemi nel tuo codice con questo sistema. Nella mia mente, questo uccide l'idea. È sempre più importante avere un codice funzionale che un codice correttamente disegnato!

Se il progetto è suddiviso in compartimenti e la maggior parte delle parti del codice tende a essere "posseduta" da singoli programmatori, allora potrebbe essere giusto lasciarli usare i propri stili (entro limiti ragionevoli). Tuttavia, se diverse persone lavorano frequentemente sullo stesso codice, è probabilmente necessario applicare uno stile.

Ecco una discussione simile su Stack Overflow .

La riformattazione automatica del codice unidirezionale può essere una soluzione praticabile se:

1. Trova un autoformatter che funzioni effettivamente per la convenzione che desideri implementare e il tuo linguaggio di programmazione.
2. Può farlo pre-commit in modo che la riformattazione non compaia nei registri delle modifiche mescolati e indistinguibili dalle effettive modifiche funzionali.
3. Fai in modo che il tuo team sia d'accordo su quale convenzione deve essere applicata (perché in generale non c'è "ritorno" al check-out per le preferenze personali di uno sviluppatore, almeno non di cui io sia a conoscenza).

Nessuno di questi è effettivamente facile da fare in molti casi, quindi considera di scegliere le tue battaglie qui! Ho visto i team farlo con successo per un progetto C # /. NET in cui la riformattazione è avvenuta già sul PC dello sviluppatore, quindi è possibile in alcune circostanze.

assolutamente puoi. Si tratta di non sudare le piccole cose.

L'unico standard che conta è "mantenere le modifiche nello stesso stile del codice esistente". Finché puoi adattarti a uno stile di codifica che non è il tuo preferito, puoi lavorare con qualsiasi stile di codifica.

Quindi qual è il grosso problema di lavorare in 3 stili diversi all'interno della stessa azienda. I tuoi sviluppatori devono capire questo, che scrivere il codice nel modo che preferiscono è trovare il loro codice ma una volta apportate modifiche a un file diverso che utilizza uno stile diverso, devono mantenere quello stile (o sembrerà davvero male) . Non è consentita la riformattazione (o si limiteranno a riformattare continuamente e le differenze scm saranno inutili) (e se lo fai, dovrebbe essere impiegato un auto formattato).

È probabile che, una volta che avranno iniziato con questo, giungeranno a un consenso su quale stile utilizzare o lo stile andrà alla deriva per la maggior parte. Se saranno infantili e riformatteranno il codice a vicenda per tutto il tempo, allora sarà il momento di scaricare uno standard da Internet e richiedere che lo utilizzino. Potresti voler farlo comunque, solo per agitarlo in faccia come una carta "gioca bene o altro".