Riformattazione e controllo della versione

21

La formattazione del codice è importante. Anche gli argomenti relativi all'indentazione . E la coerenza è più importante dei miglioramenti minori. Ma i progetti di solito non hanno una guida di stile chiara, completa, verificabile e applicata a partire dal primo giorno, e importanti miglioramenti possono arrivare ogni giorno. Forse lo trovi

SELECT id, name, address
FROM persons JOIN addresses ON persons.id = addresses.person_id;

potrebbe essere scritto meglio come / è scritto meglio di

SELECT persons.id,
       persons.name,
       addresses.address
  FROM persons
  JOIN addresses ON persons.id = addresses.person_id;

mentre si lavora per aggiungere più colonne alla query. Forse questa è la più complessa di tutte e quattro le query del tuo codice o una query banale tra migliaia. Non importa quanto sia difficile la transizione, decidi che ne vale la pena. Ma come si monitorano le modifiche al codice attraverso le principali modifiche di formattazione? Si può semplicemente rinunciare e dire "questo è il punto in cui ricominciamo", oppure è possibile riformattare tutte le query nell'intera cronologia del repository.

Se utilizzi un sistema di controllo della versione distribuito come Git, puoi ripristinare il primo commit in assoluto e riformattare la tua strada da lì allo stato corrente. Ma è un sacco di lavoro, e tutti gli altri dovrebbero mettere in pausa il lavoro (o essere preparati per la madre di tutte le fusioni) mentre sta andando avanti. C'è un modo migliore per cambiare la cronologia che offre il meglio di tutti i risultati:

  • Stesso stile in tutti i commit
  • Lavoro di unione minima

Per chiarire, non si tratta di best practice quando si avvia il progetto, ma piuttosto cosa si dovrebbe fare quando un refactoring di grandi dimensioni è stato considerato una Good Thing ™ ma si desidera comunque una cronologia tracciabile? Mai la cronologia della riscrittura è ottima se è l'unico modo per garantire che le tue versioni funzionino sempre allo stesso modo, ma per quanto riguarda i vantaggi dello sviluppatore di una riscrittura pulita? Soprattutto se hai modi (test, definizioni di sintassi o un binario identico dopo la compilazione) per assicurarti che la versione riscritta funzioni esattamente allo stesso modo dell'originale?

    
posta l0b0 28.06.2012 - 17:30
fonte

5 risposte

25

Effettua la riformattazione come commit separato. Ciò interferirà minimamente con la cronologia e dovresti essere in grado di vedere a colpo d'occhio quali sono i commit che si limitano a riformattare e che in realtà cambiano il codice. Potrebbe inclinare git blame e simili, ma se punta a un commit di solo riformattazione, è abbastanza semplice cercare prima la modifica precedente.

    
risposta data 28.06.2012 - 22:37
fonte
13

Non riscrivere la cronologia VCS: è contro i principi VCS.

Non cercare di automatizzare il fixing della formattazione: sta trattando i sintomi, non il vero problema (= gli sviluppatori che non seguono gli standard di codifica).

Definisci lo standard di codifica e le migliori pratiche di formattazione in un documento comune e fai in modo che tutti gli sviluppatori siano d'accordo.

Hai menzionato Git, che è fantastico, perché è distribuito. Con un DVCS è molto semplice applicare le best practice attraverso il workflow gatekeeper . I gatekeeper respingono uniscono le proposte (= richiama richieste in Git) che non sono conformi alle linee guida comuni. E intendo respingere , in grassetto, altrimenti il programmatore in violazione non si preoccuperà di seguire le regole e continuerà a ripetere gli stessi errori.

Questa tecnica funziona bene per me. I coder vogliono che il loro lavoro venga unito, quindi dopo alcuni errori all'inizio iniziano a seguire le regole.

Come per correggere la base di codice esistente ... Raccomando di farlo gradualmente, magari modulo per modulo, o come ha senso per il tuo progetto. Esamina attentamente ogni fase. Può sembrare stupido, ma gli errori si verificano anche con cambiamenti banali come la semplice formattazione, quindi preparati per alcuni piccoli sobbalzi sulla strada.

    
risposta data 28.06.2012 - 20:03
fonte
8

La risposta alla tua domanda attuale è "Non lo fai". Non conosco nessuno strumento SCM corrente in grado di tracciare i cambiamenti nella logica dal codice formattato in un modo, attraverso un importante cambiamento di formattazione, e attraverso ulteriori modifiche dopo che il codice è stato formattato nel nuovo modo. E, lo sai, perdere la cronologia su un pezzo di codice non è buono.

Di conseguenza, contraddirò un po 'la tua prima frase. La formattazione del codice non importa che molto. Bello è bello, ma non è quello per cui siamo qui. Comprendo tutti quelli che sono stati scaricati nel vecchio codice della variante K & R di qualcuno con i rientri a due spazi (1), ma ... la formattazione non è in realtà un ostacolo alla comprensione di ciò che accade, a meno che non sia qualcosa eccezionalmente patologico. In questo caso, avrai comunque problemi a cambiare il codice e non dovresti disturbarlo.

Pertanto, non vale la pena apportare modifiche al codice stabilito STRETTAMENTE per riformattarlo. Cambiare i nomi delle variabili, spezzare le funzioni lunghe, tutto quel materiale di refactoring che cambia il contenuto, sì, ma non SOLO la riformattazione.

1) - Una volta ero proprietario di Windows Clipboard Viewer per un po '. Il tutto era uno, 150k, modulo C. Ho trovato un punto in cui diverse persone avevano utilizzato, credo, cinque stili diversi di parentesi all'interno di trenta linee l'una dell'altra. Ma quella parte di cose ha funzionato. Ho portato avanti una stampa di quel pezzo di codice per dieci anni, ma non l'ho usato perché quella storia contava, e quel codice era in almeno tre alberi di sorgenti (Windows 3.x, NT, futuro 95) che visse tutti in diversi edifici.

    
risposta data 28.06.2012 - 23:20
fonte
3

But how do you track code changes across major formatting changes?

Modifiche alla formattazione sono modifiche al codice; trattale come qualsiasi altra modifica al tuo codice. Chiunque abbia lavorato su un progetto significativo probabilmente avrà visto bug e altri problemi che sono stati creati quando qualcuno ha deciso di "riformattare" un po 'di codice.

But it's a lot of work, and everyone else would have to pause work (or be prepared for the mother of all merges) while it's going on.

Perché devi riformattare tutto tutto allo stesso tempo? Soprattutto se la riformattazione non modifica il significato del codice, dovresti essere in grado di riformattare i file individualmente e controllarli mentre procedi. Meglio, fai in modo che tutti i membri del tuo team concordino su uno stile (altrimenti non ha alcun senso riformattare in ogni caso) e li incarichi tutti di riformattare nel corso del loro altro lavoro. Dopo un po ', avrai coperto gran parte del codice senza interrompere il resto del progetto.

    
risposta data 29.06.2012 - 22:47
fonte
1

Ci sono due possibili approcci che ho visto per questo.

1. Riformatta codice su commit-hook

Anche se inizialmente l'hair-raising altera il codice dopo averlo inviato, se la procedura di riformattazione (ad es. astyle ) non lo fa Fare del male al codice, quindi è un'operazione sicura. Nel corso del tempo l'intero team apprezzerà che tutto il codice alla fine sembra lo stesso. Chiaramente, avere test unitari / automatizzati completi assicurerà che non si sia rotto niente.

2. Riformattazione unica di tutto il codice

Questo è più pericoloso per la mia esperienza e rende difficili i problemi di tracciamento attraverso il big-bang, ma è possibile. Eseguire tutti i test in seguito è essenziale. Per lo stile di codifica, la maggior parte delle differenze ruota intorno all'uso di spazi vuoti o rientri. Si dovrebbe poter dire a uno strumento di unione decente di ignorare tutte le differenze di spazi bianchi, quindi questo aiuterà con le unioni.

    
risposta data 28.06.2012 - 18:56
fonte

Leggi altre domande sui tag