Sarebbe una cattiva idea eseguire periodicamente i formattatori di codice su un repository?

Sembra bello, ma preferirei che le persone siano responsabili per le modifiche al codice, non ai bot.

Inoltre, vuoi essere assolutamente sicuro che quei cambiamenti non infrangono nulla. Ad esempio, abbiamo una regola che ordina proprietà e metodi in ordine alfabetico. Ciò può avere un impatto sulla funzionalità , ad esempio con l'ordine dei dati e dei metodi nei file WSDL dei contratti WCF.

Vorrei invece provare a rendere davvero facile per tutti i membri del team applicare la formattazione automatica del codice in base allo standard del tuo team direttamente all'interno del tuo editor o IDE , al file del codice sorgente corrente (o selezionato) parti di esso). Questo dà ai membri del tuo team un maggiore controllo su come e quando avviene la formattazione, lascia che controllino il codice prima che venga eseguito il commit nel modulo finale e lo provi dopo che la formattazione è avvenuta , non prima.

Se tutti o la maggior parte dei membri del tuo team usano lo stesso editor, questo non dovrebbe essere troppo difficile. Se tutti ne usano uno diverso, il tuo approccio potrebbe essere la seconda soluzione migliore, purché il team lo supporti. Tuttavia, ti consiglio di installare misure di sicurezza aggiuntive, come build notturne e test automatici che vengono eseguiti dopo ogni modifica automatica del codice.

È una cattiva idea, non solo perché scoraggia le persone dallo scrivere codice decente, ma anche dal fatto che la riformattazione verrà mostrata come modifiche al codice nel tuo VCS (ne usi uno che spero), mascherando il flusso storico dello sviluppo del codice . Ancora peggio, ogni azione di formattazione del codice (anzi, ogni modifica al codice) ha la possibilità di introdurre bug, sia manuali che automatizzati. Così il tuo formattatore ora può introdurre bug nel tuo codice che non passeranno attraverso recensioni di codici, test di unità, test di integrazione, ecc. Fino a mesi forse successivi.

Tenderei a credere che sia una buona idea (per eseguire automaticamente i formattatori di codice), ma questa è solo la mia opinione.

Non li eseguirò periodicamente, ma se possibile prima che venga eseguito il controllo della versione.

Con git , un pre-commit hook fare ciò sarebbe utile. In molti progetti C o C ++ creati con alcuni Makefile , sto aggiungendo un po 'di indent target (che esegue opportunamente i formattatori di codice come indent o astyle ) e si aspettano che i contributori eseguano regolarmente make indent . A proposito, puoi anche aggiungere alcune regole di make per assicurarti che i git git siano stati installati (o per installarli).

Ma in realtà, è più un problema social che uno tecnico . Vuoi che il tuo team esegua un codice pulito e ben formattato, e questa è una regola sociale del tuo progetto. (Non c'è sempre una risposta tecnica ad ogni problema sociale).

Il controllo della versione è principalmente uno strumento per aiutare la comunicazione tra sviluppatori umani (incluso te stesso tra qualche mese). Il tuo software non ha bisogno di VC o di formattazione, ma il tuo team lo fa.

A proposito, diverse comunità e diversi linguaggi di programmazione hanno opinioni diverse sulla formattazione del codice. Ad esempio, Vai ha solo uno stile di formattazione del codice, ma C o C ++ ne hanno molti.

Penso che sia una cattiva idea. Molte delle risposte hanno già coperto che sporca la storia rendendo difficile definire chi in realtà ha aggiunto una linea e che incoraggia le persone a eseguire qualsiasi commit e il bot di formattazione lo gestirà.

Un approccio migliore sarebbe quello di incorporare un correttore di formato nel tuo strumento di costruzione. (In Java c'è Checkstyle ) Quindi, consentire alle persone di unire i loro rami al ramo principale se la generazione passa (inclusa la formattazione) .

Se permetti alle persone di impegnarsi direttamente nel ramo principale (come ad esempio in Subversion), dovrai comunque assicurarti che tutti abbiano la disciplina per eseguire il commit solo del codice formattato (o che il server accetti i commit solo dopo alcuni controlli sono stati eseguiti).

In generale, penso che sia una cattiva idea. In linea di principio è un'idea valida, ma può essere problematica nella realtà. Avere il formattatore del codice spezzare il tuo codice è una possibilità reale, e richiede solo una sessione di formattazione per far rispondere i tuoi sviluppatori con (probabilmente giustificata) ostilità (es. "Il tuo pessimo formatter di codice ha rotto la build, spegnilo ora! ").

Seguendo la raccomandazione di @ BasileStarynkevitch, utilizziamo git post-ricezione git lato server per inviare "email di consulenza" sullo stile del codice.

Se spingo un commit che contiene violazioni di stile, il server di origine git mi invierà un'e-mail che mi informa che ho infranto le linee guida di stile e consiglia di correggere il mio codice. Tuttavia, non lo applica perché potrebbero esserci validi motivi per rompere lo stile della casa (per esempio stringhe lunghe che superano il limite della lunghezza della linea).

Se si tratta di un problema sistemico che sta danneggiando il codebase, potrebbe essere il momento di iniziare a sollevare problemi di stile del codice nelle revisioni del codice. Uno stile di codice scadente può mascherare bug e rendere il codice più difficile da leggere, quindi può essere un problema di revisione del codice valido.

Per aggiungere all'aspetto "problema sociale" delle cose, può essere utile incoraggiare le persone a correggere i difetti estetici e stilistici man mano che li trovano. Abbiamo un messaggio di commit standard "Cosmetico". per le correzioni di stile del codice che altri sviluppatori sanno non contengono modifiche di rottura.

Come dice @DocBrown, un'altra opzione è quella di imporre lo stile del codice all'interno dell'IDE. Utilizziamo CodeMaid con Visual Studio per correggere molti errori di stile comuni. Verrà eseguito salvando i file di codice, il che significa che il codice di cattivo stile non dovrebbe mai nemmeno inserirlo nel repository ... in teoria: -).

Sì, penso che sia una cattiva idea. Non fraintendermi, la ragione per farlo sembra grandiosa, ma il risultato potrebbe essere ancora orribile.

Avrai conflitti di fusione quando tiri un ramo tracciato, ma temo che sia il caso, tuttavia potrei sbagliarmi.

Non voglio testarlo adesso al lavoro, ma dovresti provarlo tu stesso.

In effetti puoi semplicemente controllare un commit recente. Crea un nuovo ramo, commetti qualcosa di meschino, selezionalo o unisci senza alcun autocommit.

Quindi esegui il tuo script, tira e se il tuo risultato è un pasticcio di fusione orribile, allora non dovresti farlo, alla luce del sole.

Invece potresti potenzialmente metterlo in una build notturna o in una build settimanale.

Ma anche una notte potrebbe essere una cattiva idea.

Potresti eseguirlo settimanalmente, quando sei sicuro che non si verificheranno conflitti di fusione perché tutto è finito il lunedì.

Altrimenti eseguilo 1-2 volte all'anno durante le festività natalizie, quando non si verificheranno conflitti di fusione.

Ma la soluzione potrebbe dipendere dalla tua priorità per lo stile del codice.

Penso che fare uno script di installazione che crei automaticamente il repository git e che imposti gli hook per il progetto sia migliore.

Oppure potresti includere lo script di installazione hook in una cartella per i tuoi sviluppatori all'interno del progetto e semplicemente controllarlo in git stesso.

Qualcosa che non ho visto menzionato è il fatto che a volte ci sono motivi legittimi per non formattare qualcosa secondo un insieme di regole. A volte la chiarezza del codice viene migliorata andando contro una determinata linea guida che il 99% delle volte ha senso. Gli umani devono fare quella chiamata. In questi casi, la formattazione automatica del codice finirebbe per rendere le cose meno leggibili.

È un'idea orribile.

Se uno dei miei colleghi sviluppatori ha apportato modifiche gratuite ai file di origine, non avrebbe superato una revisione del codice. Rende solo la vita più difficile per tutti. Cambia il codice che deve essere modificato, nient'altro. Cambiamenti inutili portano a unire conflitti, che possono portare a errori, e solo creare un lavoro inutile.

Se vuoi farlo regolarmente, è semplicemente orribile.

E poi c'è la domanda su che tipo di modifiche fa il formatter del codice. Uso la formattazione automatica nel mio editor, funziona abbastanza bene e posso migliorare le cose quando la formattazione automatica non è perfetta. Se usi un formattatore di codice che va oltre, non migliorerai il codice, lo farai peggiorando.

E poi c'è il problema sociale. Ci sono persone che vogliono costringere tutti a usare il loro stile di codice e ci sono persone più flessibili. Qualcosa del genere sarebbe probabilmente suggerito dal tipo di sviluppatore "grammer-nazista" (ortografico intenzionale) che vuole forzare il proprio stile su tutti gli altri. Aspettatevi un backlash e aspettatevi che gli sviluppatori flessibili, normalmente disinvolti, mettano giù il piede.

Non menzioni il VCS che usi ma, a seconda di ciò, un'altra opzione è avere un hook lato server. Un gattino come VCS lo supporta. È possibile installare un hook sul lato sever che esegue il formattatore sulla versione da spingere e quindi confronta il file formattato con la versione che viene inviata. Se differiscono, lo sviluppatore non ha usato la formattazione corretta e il server potrebbe rifiutare la spinta. Questo costringerebbe i tuoi sviluppatori a spingere solo il codice con la formattazione desiderata, incoraggiandoli così a scrivere codice pulito fin dall'inizio, farebbe in modo che gli sviluppatori siano in grado di testare il codice formattato correttamente e di evitare che gli sviluppatori debbano installare manualmente un client gancio.

È un compromesso tra un formato di codice più pulito e una cronologia git più precisa e più facile da comprendere. Dipende dalla natura del tuo progetto e quanto spesso ti immergi nella storia del git o dalla colpa per capire cosa sta succedendo. Se stai lavorando su qualcosa di nuovo e non devi mantenere la compatibilità con le versioni precedenti, la cronologia di solito non gioca un ruolo importante.

Questa idea è simile ad altre risposte, ma non posso commentare i miei suggerimenti.

Un'opzione consiste nel impostare un alias (o hook o qualsiasi altra cosa) nella funzione di commit, che esegue il formattatore del codice sul codice to-be-commit prima che venga eseguito il commit.

Potrebbe avere 2 (o più) risultati:

1) Mostra all'utente le modifiche proposte e chiedi la loro approvazione per applicare e confermare le modifiche.

2) Ignora le modifiche proposte e applica il codice originale.

Potresti anche aggiungere più flessibilità a queste opzioni, come la possibilità di modificare le modifiche proposte nell'opzione 1. Un'altra idea (a seconda di quanto tu voglia spingere questi standard di codifica) è che il sistema ti invii un rapporto di qualche tipo quando è selezionata l'opzione 2.

Questo potrebbe essere un buon bilanciamento del controllo automatico di tutto il codice che desideri, pur consentendo agli sviluppatori di adattarsi alle loro esigenze. Consente inoltre l'opzione di non "auto-rifiutare" il codice con le differenze di formattazione come menzionato in altre risposte. Con il 'Ho rivisto e approvato le correzioni automatiche di formattazione; commit 'option, mantiene comunque la responsabilità personale per ogni sviluppatore e non fa casino con VCS.

Non lo farò sul repository ma lo farò su save se lo strumento lo supporta. Eclipse è uno e in più farei la pulizia del codice incluso l'ordinamento.

La parte interessante è che fa parte del progetto, quindi ogni sviluppatore lo otterrà per il proprio progetto.

Come un ulteriore vantaggio, le fusioni sarebbero notevolmente semplificate dal momento che le cose non salteranno.

Le revisioni del codice prevengono eventuali errori.

Un altro posto dove vorrei farlo è far parte della build. Nel mio caso, è così che maven builds riformatterà l'XML e pulirà i file pom e riformatterà il codice.

In questo modo, quando gli sviluppatori sono pronti a spingerlo, tutto verrà ripulito per la loro richiesta di pull.