Flusso di lavoro per la formattazione git / codice / commit hooks ecc

2

Il nostro team sta crescendo, e con esso, il malcontento rispetto agli standard comuni di codifica imposti agli sviluppatori con opinioni alternative (forti, al limite religiose) su ciò che costituisce un buon stile di codifica.

Esempi di punti di maggiore controversia:

  • spazi vs schede
  • Posizionamento di parentesi graffe (K & R, GNU, kernel Linux, Stroustrup ecc.)
  • L'elenco continua ...

Vorremmo renderlo più flessibile, consentendo agli sviluppatori di adottare uno stile che si adatti ai loro gusti.

Applicazione del codice nel repo conforme

Possiamo installare un hook di pre-commit che eseguirà uno script in formato clang sulle modifiche da impegnare, l'applicazione di tutto il codice nel nostro repository è conforme a uno stile comune.

Permettere agli sviluppatori di lavorare con il loro stile

È plausibile che potremmo anche installare un hook post-checkout , consentendo agli sviluppatori di applicare il proprio stile sul codice.

Il problema che vedo con questo è che tutti i file appariranno come "sporchi" se confrontati con git status o git diff ecc.

Domanda:

Esistono tooling / workflow in cui possiamo avere il meglio dei due mondi - uno stile comune che è quello a cui i file controllati nel repository sono conformi e gli stili specifici degli utenti che possono essere applicati ai repository locali durante lo sviluppo, < em> senza "scherzare" con git ?

    
posta Steve Lorimer 22.09.2017 - 01:40
fonte

1 risposta

1

No. Sebbene sia tecnicamente possibile convertire il codice tra gli stili non sarà mai perfetto al 100%.

Quindi introdurre un flusso di lavoro automatizzato che converte in un modo al momento del check out e un altro al momento del check-in sarà pieno di problemi.

Il modo di affrontare questo problema non è quello di imporre uno stile. Ognuno codifica in modo diverso e gli stili cambiano nel tempo.

Gli sviluppatori devono imparare a leggere e lavorare negli stili di altre persone.

"Non riesco a correggere quell'errore perché il codice ha linguette e non spazi" non è una scusa accettabile.

"Ho corretto un errore di ortografia .. e ho anche ridisegnato tutto lo stile per il modo in cui mi piace" Non è un modo accettabile di lavorare.

"Non accetto il codice che hai scritto perché non mi piace lo stile" È altrettanto cattivo.

Tutte queste cose perdono tempo. Bitching sul miglior stile in fondo al pub è molto divertente. Ma passare ore a farlo funzionare è una perdita di tempo.

    
risposta data 22.09.2017 - 11:25
fonte

Leggi altre domande sui tag