Cosa intendi con "il mio editor"? E cosa intendi con "git -w"? Stai usando un editor e strumenti da riga di comando al posto di un IDE? Posso consigliare IntelliJ IDEA? È il miglior IDE mai di java, e non ha alcun problema con nessuno dei due tipi di spazi bianchi, o anche con spazi bianchi misti all'interno dello stesso file.
In genere, se una modifica di grandi dimensioni ha viene apportata al codice base, come la modifica della formattazione, dovrebbe essere eseguita tutto in una volta e il prima possibile.
Se non lo fai, i file continueranno a essere impegnati in futuro senza alcun motivo diverso dalle modifiche dello spazio bianco, inutilmente gonfiando gli elenchi della cronologia e obbligandoti a richiedere spesso diff di file solo per dirti "i file differiscono solo negli spazi bianchi ".
Inoltre, non sarà mai ovvio se un file è stato commesso a causa di modifiche effettive o solo a causa di cambiamenti di spazi bianchi, quindi se due o più sviluppatori hanno sbocchi spazio e / o formattazione diversi per errore, ci vorranno alcuni tempo e diversi commit in cui uno sviluppatore sta annullando le modifiche degli spazi bianchi di un altro fino a quando non ci si rende conto che questa discrepanza esiste.
Riformattando e commettendo tutto in una volta, il numero di revisione di quel commit (che da quel giorno in poi sarà conosciuto come "The Great Big Reformatting") verrà memorizzato da tutti, quindi ogni volta che vedi quel numero di revisione lo saprai per non richiedere nemmeno un diff.
Inoltre, da quel momento in poi, tutti sapranno che i successivi commit dovuti a cambiamenti di spazi bianchi dovrebbero essere non fatti, perché sono ovviamente il risultato di una mancata corrispondenza tra gli sviluppatori.
Emendamento
Ora, sulla questione di se dovresti convertire l'intero codice base per conformarsi a uno stile di codifica particolare, non è una cosa facile rispondere senza conoscere i particolari della tua situazione. La risposta ovvia, che chiunque là fuori ti dirà, è che uno stile di codifica coerente è importante, e che anche uno cattivo (qualunque sia lo standard) ma uno stile coerente è migliore di uno stile incoerente . Tuttavia, ci sono alcune domande pratiche da porre per prime:
-
La maggior parte dei contributori importanti sul posto di lavoro è d'accordo?
-
Ci sono dei contributori che, pur essendo una minoranza, potrebbero smettere di andarsene se procederai con questo? E quanto sono importanti?
-
Quanto è grande una varietà di stili? Si tratta solo di schede vs spazi o include altri aspetti importanti dello stile di codifica come Allman vs. parentesi graffe egiziane? Le persone dovrebbero essere abbastanza flessibili da non preoccuparsi di una piccola varietà.
-
Ma soprattutto: È davvero necessario?
Voglio dire, nel mio attuale lavoro, ogni sviluppatore sta lavorando su un sottoinsieme specifico e chiaramente delineato del codice base, quindi non mi dilungo (molto) nel codice degli altri, e nessuno approfondisce il mio codice, quindi non importa che abbiamo stili molto diversi. Non mi prende in tasca né mi rompe la gamba che un collega avvolge le sue linee alla colonna 80. (Ssssh, probabilmente non sa come modificare l'impostazione pertinente.) La situazione sarebbe molto diversa se avessimo sviluppatori il cui lavoro comportava frequenti scambi con il codice di altre persone. Se si dispone di una situazione del genere e se gli stili di codifica variano così tanto da rendere difficile per loro svolgere il proprio lavoro, probabilmente si dovrebbe applicare uno stile di codifica unico per tutti. Altrimenti, forse no.
Un'ultima nota finale:
In teoria, dovrebbe essere possibile risolvere questo problema con mezzi tecnici in modo che a) diversi sviluppatori possano lavorare sullo stesso codice, e tuttavia b) ogni sviluppatore possa godere di qualsiasi stile di codifica preferisca. Il modo in cui questo sarebbe (in teoria) realizzato sarebbe avere il codice formattato secondo lo stile preferito durante l'aggiornamento dal sistema di controllo della versione, e riformattato nello "stile del progetto" subito prima del commit. Sfortunatamente, ad oggi, non ci sono strumenti che lo faranno per quanto ne so. IntelliJ IDEA si avvicina sostenendo più stili, tra cui uno "stile personale" e uno "stile di progetto", ma non è completamente automatizzato: si può ancora sfogliare il codice non modificato in "stile progetto", se si riformattano i file in il tuo "stile personale" apparirà sfortunatamente come modificato rispetto alle copie incontaminate, (che è probabilmente un difetto del sistema di controllo delle versioni e non di IDEA) e il passaggio (facoltativo ovviamente) che ri-formatta i file in lo "stile di progetto" al momento del commit lascia di nuovo tutte le copie locali in "stile progetto". Se qualcuno sa qualcosa che raggiunge più di quello, per favore dì.