2009-05-24 9 views
7

Quali prodotti di controllo sorgente hanno una funzione "diff" che ignora lo spazio bianco, le parentesi graffe, ecc., Nel calcolo della differenza tra le versioni registrate? Mi sembra di ricordare che il diff di Clearcase ha fatto questo, ma Visual SourceSafe (o almeno la versione che ho usato) no.Differenza di formattazione e controllo del codice sorgente

Il motivo per cui lo chiedo è probabilmente piuttosto tipico. Quattro sviluppatori perfettamente ragionevoli in una squadra hanno quattro modi completamente diversi di formattare il loro codice. Dopo aver verificato il codice modificato da qualcun altro, ognuno eseguirà immediatamente una specie di macro di programma o editor per formattare le cose come preferiscono. Fanno cambiamenti effettivi al codice. Accedono ai loro cambiamenti. Vanno in vacanza. Due giorni dopo quel programma, che funzionava da due anni, esplode. Lo sviluppatore assegnato al bug fa una diff tra le versioni e trova 204 differenze, di cui solo 3 hanno un significato, perché l'algoritmo diff è zoppo.

Sì, è possibile avere standard di codifica. Molti li trovano terribili. Una soluzione in cui tutti possono avere la loro torta e mangiarla sembra molto più preferibile.

=========

EDIT: Grazie a tutti per alcuni ottimi consigli.

Nei prendo lontano da questo è:

(1) Un sistema di controllo di origine con innesto tipo diff è preferibile.

(2) Trova un diff con le opzioni adatte.

(3) Utilizzare un buon programma di formattazione di origine e stabilirsi su uno standard di check-in.

Suona come un piano. Grazie ancora.

+0

Clearcase ha la possibilità di ignorare vuota differenze. –

risposta

2

Forse dovresti scegliere un formato ed eseguire uno strumento di indentazione prima del check-in in modo che ogni persona possa verificare, riformattare in base alle proprie preferenze, apportare le modifiche, riformattare lo standard ufficiale e quindi effettuare il check-in?

Un paio di passaggi aggiuntivi, ma già utilizzano gli strumenti di indentazione quando si lavora. Forse può essere uno script di check-in attivato?

Modifica: questo forse risolverebbe anche il problema del controvento.

(Non ho provato questa soluzione da solo, da qui i "peripezzi" e "maybes", ma sono stato in progetti con gli stessi problemi, ed è un dolore cercare di passare attraverso diff con centinaia di irrilevanti modifiche che non sono limitate agli spazi bianchi, ma include la formattazione stessa.)

+1

No, porta la tua squadra sulla stessa pagina. http://stackoverflow.com/questions/903754/do-you-still-limit-line-length-in-code/904008#904008 – bendin

+0

@bendin, cosa intendi? – FeatureCreep

0

Subversion supporta questo aspetto, in modo nativo nelle versioni più recenti, o utilizzando un diff alternativo come Gnu Diff.

4

Git ha queste opzioni:

  • --ignore-space-at-eol

    Ignora cambiamenti di spazi bianchi a EOL.

  • -b, --ignore-space-change

    Ignora cambiamenti nella quantità di spazi bianchi.Questo ignora lo spazio bianco alla fine della riga e considera tutte le altre sequenze di uno o più caratteri dello spazio bianco equivalenti.

  • -w, --ignore-all-space

    Ignora spazi bianchi quando si confrontano le linee. Questo ignora le differenze anche se una riga ha uno spazio bianco in cui l'altra linea ha nessuno .

Non sono sicuro che le modifiche delle parentesi possono essere ignorate utilizzando la diff di Git.

Se si tratta di codice C/C++, è possibile definire le regole Astyle e quindi convertire lo stile di parentesi del codice sorgente in quello desiderato, utilizzando Astyle. A git diff produrrà quindi l'output sensato.

0

Beyond Compare fa questo (e molto altro) ed è possibile integrarlo in Subversion o Sourcesafe come strumento di diffusione esterno.

0

Come spiegato in , è più una questione di associare il giusto strumento di diff al tuo VCS preferito, piuttosto che fare affidamento sull'opzione VCS corretta (anche se Git ha alcune opzioni riguardo gli spazi bianchi, come quella menzionata in Alan's answer, non sarà sempre completo come si vorrebbe).

DiffMerge è il più completo su quelle opzioni "ignora", in quanto non solo può ignorare gli spazi ma anche altre "variazioni" in base al linguaggio di programmazione utilizzato in un determinato file.

4

Scegli uno standard di codice (terribile), annota in alcuni documenti ufficiali sugli standard di codifica e vai avanti con la tua vita, scherzare con gli spazi non è un lavoro produttivo.

E ricorda che sei uno sviluppatore professionista, il tuo compito è portare a termine il progetto, modificare qualsiasi cosa nel codice a causa di una preferenza di stile personale che danneggia il progetto - non renderà più difficile diffondere, può anche introdurre È difficile trovare problemi se il formatter o il compilatore di origine ha dei bug (e il tuo fantastico strumento diff non ti salverà quando due colleghi inizieranno a litigare sul case).

E se qualcuno proprio non è d'accordo di lavorare con lo stile selezionato solo lui (o lei) ricordare che lui è la programmazione come professione non come un hobby, vedere http://www.ericsink.com/entries/No_Great_Hackers.html

+0

+1 - prova con codice Python e guarda le scintille volare! – richq

Problemi correlati