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

No, dovrai fare uno standard. Se il tuo membro del team B cambia (con uno strumento IDE automatizzato o manualmente) un intero mucchio di membro del team di codice A ha scritto, che verrà eseguito il commit e visualizzato come una modifica.

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 linea di base e adottarli per soddisfare la tua squadra.

Avere uno stile di codifica coerente aiuterà anche nella manutenibilità del progetto e ridurrà la barriera all'ingresso di 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 su cui stai lavorando.

Sì, può funzionare fintanto che gli stili sono tutti ragionevoli e le persone non vanno in giro cambiando 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'assegnare il vecchio codice creato a uno "standard" diverso dal tuo e doverlo integrare con il tuo codebase.
Quindi, se devi farlo, alcune linee guida:

• non cambiare codice in stile diverso per soddisfare le tue preferenze, costa tempo e introduce bug
• rimangono coerenti all'interno di un singolo file. Quindi se lo stile A era usato inizialmente per scriverlo, tutti useranno lo stile A quando lo modificano
• 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 all'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 indentazione di linea è migliore.

L'obiettivo di un documento standard dovrebbe essere quello di far rispettare / suggerire una serie di standard / convenzioni di codifica comuni che indirizzano

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

I documenti standard aiutano a garantire che il codice sia facile da leggere, mantenere e coerente nelle sue convenzioni.

Ciò è di valore inestimabile quando si esamina il codice prima di effettuare il check-in, eseguire il debug di un codice Elses o modificare il codice diversi anni dopo che lo sviluppatore originale ha lasciato la società.

Normalmente durante la creazione di un documento sugli standard di codifica riesaminare gli standard del settore per la lingua che sto usando (C, C #, SQL), utilizzare gli standard più appropriati, diffondere agli sviluppatori più importanti / influenti per commenti, incorporare i commenti dove appropriato e quindi rilasciare il documento.

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

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

Se il progetto è suddiviso in compartimenti, e la maggior parte delle parti del codice tendono ad essere "possedute" dai singoli programmatori, allora può essere giusto lasciare che usino i propri stili (entro limiti ragionevoli). Tuttavia, se molte persone lavorano spesso sullo stesso pezzo di codice, è probabilmente necessario imporre uno stile.

Ecco una discussione simile su Stack Overflow .

Il codice di riformattazione automatica a una via 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 venga visualizzata nei log delle modifiche mischiati e indistinguibili dalle effettive modifiche funzionali.
3. Gestisci per far concordare la tua squadra su quale convenzione deve essere applicata (perché in generale non c'è "ritorno" al check-out per le preferenze personali di uno sviluppatore, almeno non che io sappia)

In molti casi, nessuno di questi è facile da fare, quindi prendi in considerazione la possibilità di scegliere le tue battaglie qui! Ho visto i team fare questo con successo per un progetto C # /. NET in cui la riformattazione è già avvenuta 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 codice nel modo in cui gli piace è trovare il loro codice, ma una volta apportate modifiche a un file diverso che utilizza uno stile diverso, hanno per mantenere quello stile (o sarà davvero brutto). Nessuna riformattazione è consentita (altrimenti verranno riformattati continuamente e le differenze di scm saranno inutili) (e se lo fai, allora dovrebbe essere usato un formattato automatico).

È probabile che, una volta arrivati a questo punto, arrivino a un certo consenso su quale stile usare o loro stile andranno alla deriva insieme per la maggior parte. Se saranno infantili al riguardo e si riformeranno a vicenda codificando per tutto il tempo, allora sarà il momento di scaricare uno standard da Internet e chiedergli di usarlo. Potresti volerlo fare comunque, solo per agitarlo in faccia come una carta "gioca bene o altro".