Il codice di formattazione è una cosa brutta quando si utilizza un VCS?

Question

Il codice di formattazione è una cosa brutta quando si utilizza un VCS?

#1 da (41 voti)
#2 da (29 voti)
#3 da (10 voti)
#4 da (4 voti)
#5 da (2 voti)

24

Quasi sempre formatto il mio codice prima di impegnarmi per assicurarmi che sia eseguito correttamente. La maggior parte della mia squadra non si preoccupa e non sempre formatta il codice in modo corretto (cose secondarie che non influenzano il codice ma influenzano la leggibilità quando si tenta di mantenerlo).

Recentemente ho installato gli elettroutensili VS con un'opzione "Format on save" e ho apportato una modifica a un file che non era stato formattato in precedenza. Il VP dello sviluppo è venuto da me e mi ha rimproverato per la formattazione poiché si vede nello strumento di fusione come se avesse cambiato quasi l'intero file, invece di una riga o due (quindi non può vedere esattamente cosa ho modificato facilmente), e mi ha detto di disabilitare il formato su save in futuro. Mentre capisco questa preoccupazione, a volte trovo difficile scegliere il codice non formattato, e IMO dovrebbe essere formattato correttamente tutto il tempo comunque. Nota che non sto solo riformattando le cose per un capriccio, ma mentre scrivo codice userò lo strumento di alimentazione o premo il tasto per formattare il testo per renderlo più facile da leggere, e in SVN questo si presenta come una modifica.

Quindi chiedo, è sempre la formattazione del codice in realtà una cosa negativa? Le sue preoccupazioni sono più valide che assicurarsi che il codice sia leggibile?

code-formatting

posta Allan Wight 13.06.2011 - 16:59

fonte

5 risposte

Leggi altre domande sui tag code-formatting

Molte classi piccole rispetto all'eredità logica (ma) complessa Come aggiungere un nuovo sviluppatore al team

score 41 · Answer 1

Per prima cosa, la tua squadra deve scegliere una convenzione di formattazione e attenersi a questa. Devi raggiungere un accordo e far rispettare a tutti gli altri, in modo da non avere persone che combattono su come dovrebbero essere le cose. Questo non dovrebbe essere solo qualcosa che fai da solo.

Per quanto riguarda la tua vera domanda. Il codice di formattazione non è una cosa negativa. Ciò che è male è apportare importanti modifiche alla formattazione nello stesso commit delle modifiche al codice. Quando la tua squadra raggiunge il consenso su come le cose dovrebbero essere formattate, fai un passaggio attraverso il codice e formatta tutto. Controlla questo da solo. Il messaggio di commit chiarirà che le modifiche sono solo spazio bianco e non sono funzionali. Quindi, quando è necessario apportare modifiche funzionali, si trovano in un commit diverso in modo che possano essere chiaramente visualizzati.

score 29 · Answer 2

No, il codice di formattazione è molto importante . Tuttavia, i commit dovrebbero essere eseguiti in due gruppi:

Modifiche cosmetiche : tutto ciò che rende il codice più leggibile.
Le altre modifiche - tutto il resto che influisce sul codice.

Utilizza il messaggio di commit per indicare che sono stati modificati solo i cosmetici. Questi possono essere saltati facilmente durante la ricerca di modifiche più sostanziali.

score 10 · Answer 3

10

Entrambi avete un punto, ma potete ottenere entrambi ciò che volete. Formattare prima il codice, controllare solo la modifica. Successivamente, apporta le modifiche funzionali e controlla come in un secondo passaggio.

risposta data 13.06.2011 - 17:05

fonte

score 4 · Answer 4

Anche io sono un selettore di formattazione, quindi ecco alcuni suggerimenti:

Primo passaggio obbligatorio: consente al team di concordare alcuni standard di formattazione di base, come tabulati, spazi, posizioni dei contrasti, stili di commento, ecc. Ora le modifiche di formattazione non essere una sorpresa completa per tutti e non calpestare le dita dei piedi.
Pulisci la formattazione solo attorno al codice che cambi. Se apporti modifiche a una sola funzione, ripulisci quella funzione. Almeno nel tempo avrai un codice più bello.
Esegue le principali revisioni di formattazione come un commit separato, senza altre modifiche al codice. Dovresti farlo solo quando hai meno probabilità di voler confrontare il codice dopo la modifica prima della modifica, dal momento che il confronto con un diff come quello può essere fastidioso. Di solito eseguo le pulizie come prima cosa prima di un importante sviluppo su quel codice.
Ottieni uno strumento di differenziazione valido che può eseguire la marcatura dipendente dalla lingua di modifiche significative e modifiche non significative. Anche il mio preferito diff Oltre il confronto contrassegna i cambiamenti effettivi del codice in un colore e gli spazi bianchi / commentano solo le differenze in un altro.

modifica per un altro suggerimento:

Varia dalla lingua alla lingua, ma per la maggior parte delle modifiche cosmetiche al codice, dovresti essere in grado di confrontare i binari compilati prima e dopo una pulizia importante per essere assolutamente sicuro di non averlo fatto.

score 2 · Answer 5

Non dovresti riformattare e commettere modifiche al codice di altre persone a meno che:

sei il gestore che sta tentando di stabilire standard di codifica per i team
il tuo responsabile ti ha chiesto di pulire il codice per aderire agli standard di codifica del team
stai pulendo il codice da uno sviluppatore non più sul tuo team per aderire agli standard di codifica del team.

Noterai che in tutti i casi mi riferisco agli standard di codifica del team. Sono un strong sostenitore di standard di codifica ragionevoli e concordati per la squadra. Se li hai, lo sviluppatore originale dovrebbe tornare indietro e pulire il suo codice per rispettare gli standard del team, non dovresti farlo dietro le spalle. Se non hai standard (e dovresti), non dovresti modificare il codice di un altro membro del team per aderire alle tue filosofie, specialmente alle loro spalle. Ricorda che fai parte di un team e mentre gli standard di codifica sono importanti, così come la fiducia e il rispetto tra i membri del team.