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

Sto pensando di creare un cron job che verifica il codice, esegue i formattatori del codice su di esso e, se qualcosa è cambiato, esegue il commit delle modifiche e le respinge.

La maggior parte dei progetti che utilizzano autoformatters li inserisce in un hook git, ma farlo automaticamente ogni poche ore eliminerebbe l'onere per ogni sviluppatore di installare il hook git.

Vorrei comunque incoraggiare tutti a scrivere codice pulito e ben formattato, e forse potrei avere il sistema automaticamente il ping degli sviluppatori quando il codice che scrivono viene riformattato, quindi sanno cosa fare in futuro.

Sembra bello, ma preferirei avere persone responsabili di commettere modifiche al codice, non robot.

Inoltre, vuoi assolutamente assicurarti che quei cambiamenti non rompano nulla. Ad esempio, abbiamo una regola che ordina alfabeticamente proprietà e metodi. Ciò può avere un impatto sulla funzionalità , ad esempio con l'ordine di dati e 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 dell'editor o dell'IDE , al file di codice sorgente corrente (o parti selezionate di esso). Ciò offre ai membri del team un maggiore controllo su come e quando avviene la formattazione, consente loro di ispezionare il codice prima che venga eseguito il commit nel modulo finale e testarlo dopo che è avvenuta la formattazione , non prima.

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

È una cattiva idea, non solo perché scoraggia le persone dalla scrittura di codice decente, ma anche perché la riformattazione apparirà come modifiche al codice nel tuo VCS (ne usi uno spero), mascherando il flusso storico dello sviluppo del codice. Ancor peggio, ogni azione di formattazione del codice (in effetti ogni modifica al codice) ha la possibilità di introdurre bug, sia manuali che automatici. Quindi il tuo formatter ora può introdurre bug nel tuo codice che non saranno sottoposti a revisioni del codice, test di unità, test di integrazione, ecc. Fino a possibilmente mesi dopo.

Tenderei a credere che sia una buona idea (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 sarebbe utile un hook pre-commit . In molti progetti C o C ++ creati con alcuni Makefile , sto aggiungendo un indenttarget (che esegue opportunamente formattatori di codice come indento astyle) e mi aspetto che i collaboratori make indentvengano eseguiti regolarmente. A proposito, puoi anche aggiungere alcune makeregole per assicurarti che gli hook git siano stati installati (o per installarli).

Ma in realtà, è più un problema sociale che tecnico . Vuoi che il tuo team impegni 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 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, Go 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à spiegato che sporca la storia rendendo difficile individuare chi ha effettivamente aggiunto una linea e che incoraggia le persone a impegnare qualsiasi cosa e il bot di formato la gestirà.

Un approccio migliore sarebbe quello di incorporare un controllo formato nel tuo strumento di creazione. (In Java c'è Checkstyle ) Quindi, consenti alle persone di unire i loro rami al ramo principale solo se la build 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 di impegnare solo codice formattato (o fare in modo che il server accetti i commit solo dopo l'esecuzione di alcuni controlli ).

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

Allo stesso modo della raccomandazione di @ BasileStarynkevitch, usiamo hook git post-ricezione sul lato server per inviare "e-mail di consulenza" sullo stile del codice.

Se invio 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 mi consiglia di correggere il mio codice. Tuttavia, ciò non lo impone perché potrebbero esserci validi motivi per interrompere lo stile della casa (ad esempio stringhe lunghe che superano il limite di lunghezza della linea).

Se si tratta di un problema sistemico che sta danneggiando la base di codice, potrebbe essere il momento di iniziare a far emergere problemi di stile del codice nelle revisioni del codice. Uno stile di codice scadente può mascherare i 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 quando li trovano. Abbiamo un messaggio di commit standard "Cosmetico". per le correzioni di stile di codice che altri sviluppatori sanno non contengono modifiche sostanziali.

Come dice @DocBrown, un'altra opzione è quella di applicare lo stile del codice all'interno dell'IDE. Usiamo CodeMaid con Visual Studio per correggere molti errori di stile comuni. Funzionerà con il salvataggio dei file di codice, il che significa che il codice di cattivo stile non dovrebbe mai farlo nel repository ... in teoria :-).

Sì, penso sia una cattiva idea. Non fraintendetemi, il motivo per farlo sembra fantastico, ma il risultato potrebbe essere ancora orribile.

Avrai conflitti di unione quando tiri un ramo tracciato, almeno temo che sarebbe il caso, potrei sbagliarmi però.

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

In effetti puoi semplicemente dare un'occhiata a un commit recente. Crea un nuovo ramo, commetti qualcosa di meschino, scegli la ciliegia o unisci senza autocommit.

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

Invece potresti potenzialmente metterlo in una build notturna o settimanale.

Ma anche una notte potrebbe essere una cattiva idea.

Puoi eseguirlo settimanalmente, quando sei sicuro che non sorgeranno conflitti di unione perché tutto è finito il lunedì.

Altrimenti eseguirlo 1-2 volte l'anno durante le festività natalizie, quando non si verificheranno conflitti di unione.

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

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

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 terribile.

Se uno dei miei colleghi sviluppatori ha apportato modifiche gratuite ai file di origine, non passerebbe una revisione del codice. Rende solo la vita più difficile per tutti. Modifica il codice che deve essere modificato, nient'altro. Cambiamenti inutili portano a unire conflitti, che possono portare a errori, e creano semplicemente 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 è meno che perfetta. Se usi un formattatore di codice che va oltre, non migliorerai il codice, ma lo peggiorerai.

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 verrebbe probabilmente suggerito dal tipo di sviluppatore "grammatic-nazi" (ortografia intenzionale) che vuole forzare il proprio stile su tutti gli altri. Aspettatevi un contraccolpo e aspettatevi che gli sviluppatori flessibili e normalmente accomodanti mettano piede.

Non menzioni il VCS che usi ma a seconda di un'altra opzione è avere un hook sul lato server. Un VCS come git lo supporta. È possibile installare un hook sul lato server che esegue il formattatore sulla versione che viene inviata e quindi confronta il file formattato con la versione che viene inviata. Se differiscono, lo sviluppatore non ha utilizzato la formattazione corretta e il server ha potuto rifiutare il push. Ciò costringerebbe i tuoi sviluppatori a spingere il codice solo con la formattazione desiderata, incoraggiandoli così a scrivere codice pulito dall'inizio, renderebbe gli sviluppatori responsabili di aver testato il codice correttamente formattato e alleviare i tuoi sviluppatori dal dover installare manualmente un lato client gancio.

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

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

Un'opzione è impostare un alias (o hook, o qualsiasi altra cosa) sulla funzione di commit, che esegue il formattatore di codice sul codice da impegnare prima che venga eseguito il commit.

Potrebbe avere 2 (o più) risultati:

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

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

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

Questo può essere un buon compromesso tra il controllo automatico di tutto il codice desiderato e allo stesso tempo la flessibilità per gli sviluppatori di soddisfare le loro esigenze. Inoltre, consente di non "rifiutare automaticamente" il codice con differenze di formattazione, come indicato in altre risposte. Con 'Ho esaminato e approvo le correzioni automatiche di formattazione; commit 'opzione, mantiene ancora la responsabilità personale per ogni lavoro degli sviluppatori e non scherza con VCS.

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

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

Poiché un ulteriore bonus le fusioni sarebbero notevolmente semplificate poiché le cose non andranno in giro.

Le revisioni del codice prevengono eventuali errori.

Un altro posto in cui lo farei è averlo parte della build. Nel mio caso ce l'ho in modo tale che build maven riformatteranno l'XML e ripuliranno i file pom e riformatteranno il codice.

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