La formattazione del codice è una cosa negativa quando si utilizza un VCS?

24

Quasi sempre formatto il mio codice prima di impegnarmi per assicurarmi che sia fatto correttamente. Alla maggior parte del mio team non importa davvero e non sempre formatta correttamente il loro codice (cose minori che non influiscono sul codice ma influiscono sulla leggibilità quando provano a mantenerlo).

Di recente ho installato gli elettroutensili VS con l'opzione "Formatta al salvataggio" e ho apportato una modifica a un file che non era stato formattato in precedenza. Il vicepresidente dello sviluppo è venuto da me e mi ha rimproverato per la formattazione poiché si presenta nello strumento di fusione come se fosse cambiato quasi l'intero file, anziché solo 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 ordinare il codice che non è formattato e IMO dovrebbe comunque essere formattato correttamente in ogni momento. Nota che non sto solo riformattando le cose per un capriccio. Ma mentre scrivo il codice o userò lo strumento di potere o premerò il comando chiave per formattare il testo per renderlo più facile da leggere, e in SVN questo appare come una modifica.

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

code-formatting

— Allan Wight
fonte

8

ha ragione, quindi perché non far sì che tutto il team usi anche lo strumento di formattazione sul salvataggio, quindi tutti otterrete un codice ben formattato che è facile da leggere e facile da visualizzare.

— gbjbaanb,

12

La maggior parte dei buoni strumenti di confronto dei file ha un filtro per "differenze non importanti" o "ignora spazi bianchi". Alcuni, come Beyond Compare, vengono forniti con filtri specifici della lingua predefiniti. Usalo a tuo vantaggio se ce l'hai.

— Michael K,

7

La formattazione del codice è importante quanto le modifiche apportate. La leggibilità deve essere una delle massime priorità quando si fa parte di una squadra. Il tuo vicepresidente dovrebbe saperlo ed esserne preoccupato.

— Edgar Gonzalez,

@Edgar: +1. Il vicepresidente è troppo esigente. La leggibilità prima ... e un'opzione ignora spazi vuoti significa che questo non è un grosso problema. E significa anche che c'è un problema più grande perché al resto della squadra non importa. Il vicepresidente dovrebbe essere più preoccupato per questo.

— quick_now

41

Prima di tutto, il tuo team deve scegliere una convenzione di formattazione e attenersi ad essa. Devi raggiungere un accordo e far sì che tutti si attengano ad esso in modo da non avere persone che litigano su come dovrebbero essere le cose. Questo non dovrebbe essere solo qualcosa che fai da solo.

Per quanto riguarda la tua vera domanda. La formattazione del codice non è una cosa negativa. Ciò che è male è apportare importanti modifiche alla formattazione nello stesso commit delle modifiche al codice. Quando il tuo team raggiunge un consenso su come devono essere formattate le cose, passa attraverso il codice e formatta tutto. Controllalo da solo. Il messaggio di commit chiarirà che le modifiche sono solo spazi bianchi e non funzionali. Quindi, quando è necessario apportare modifiche funzionali, si trovano in un commit diverso in modo che possano essere visti chiaramente.

— unholysampler
fonte

non è ancora utile se si desidera confrontare le modifiche apportate da diverse revisioni fa, ma è meglio della modifica del codice + delle modifiche di formato in 1 passaggio. Naturalmente, questa risposta vale anche per il refactoring.

— gbjbaanb,

1

+1: Oltre a questo, è bene usare qualcosa come Stylecop o qualche altro strumento che formatta automaticamente e rafforza lo stile. Quindi, sincronizza le impostazioni tra tutti i membri del team in modo che la formattazione sia coerente per tutti e non devi necessariamente ricordare qual è la regola del formato "giusto".

— Ryan Hayes,

3

Se il PO è stato rimproverato per aver tentato di formattare un documento, qualcosa mi dice che non sarebbe in grado di suggerire di usare StyleCop.

— Wayne Molina,

3

@gbjbaanb: Sì. Ecco perché è meglio prendere questo tipo di decisioni all'inizio. Il progetto in cui mi trovo ora ha le impostazioni del formatter di Eclipse controllate nel repository, quindi sappiamo che tutti hanno le stesse impostazioni.

— unholysampler,

1

@quickly_now: ecco perché abbiamo manager con diritto di veto. Se le persone non sono d'accordo, possono prendere una decisione.

— unholysampler,

29

No, la formattazione del codice è molto importante . Tuttavia, gli commit dovrebbero essere eseguiti in due gruppi:

Modifiche estetiche : tutto ciò che rende il codice più leggibile.
Le altre modifiche : tutto il resto che influenza il codice.

Utilizzare il messaggio di commit per indicare che sono stati modificati solo i cosmetici. Questi possono essere facilmente ignorati quando si cercano modifiche più sostanziali.

— JK
fonte

3

Inoltre, è anche buona norma decidere una determinata convenzione di formattazione tra il proprio team. Non solo formattare il codice di altre persone senza prima discuterne.

— Steven Jeuris,

Sì .. Ma sai, a volte è così allettante formattare quel maledetto casino "mentre ci sei". Inoltre, provare a separare i cambiamenti estetici dai cambiamenti funzionali può essere una seccatura se usi VS e formatta automaticamente qualcosa. Oh, e nessuno dirà che stai facendo una stupida formattazione mentre hai compiti molto importanti da fare guardando la cronologia dei commit

— Dyppl

10

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

— PeterAllenWebb
fonte

3

Penso che questa sia la soluzione migliore per la tua situazione attuale, ma dovresti parlarne con il tuo team. Tuttavia, hai un problema più grande, che è la mancanza di uno standard di codifica.

— Thomas Owens

2

Concordato. Mi chiedo se l'ambiente del PO sia uno di quei posti da cowboy in cui gli standard vengono evitati per "far girare le cose in fretta".

— Wayne Molina,

4

Sono anche un nit-picker di formattazione, quindi ecco alcuni suggerimenti:

Primo passo richiesto: fai in modo che il team sia d'accordo su alcuni standard di formattazione di base, come schede vs. spazi, posizioni di controvento, stili di commento, ecc. Ora le modifiche alla formattazione non saranno una sorpresa completa per tutti e non farai un passo avanti sulle dita dei piedi.
Pulisci la formattazione solo attorno al codice che modifichi. Se apporti modifiche a una sola funzione, pulisci quella funzione. Almeno nel tempo avrai un codice più bello.
Effettua importanti revisioni di formattazione come commit separato, senza altre modifiche al codice. Dovresti farlo solo quando hai meno probabilità di voler confrontare il codice dopo la modifica a prima della modifica, poiché il confronto tra un diff come quello può essere fastidioso. Di solito faccio le pulizie come prima cosa prima dello sviluppo di quel codice.
Ottieni un buon strumento diff che può fare marcature dipendenti dalla lingua di cambiamenti significativi e cambiamenti non significativi. Anche la mia differenza preferita Beyond Compare segna le effettive modifiche al codice in un colore e gli spazi / commenti solo differenze in un altro.

modifica per un altro suggerimento:

Varia dalla lingua alla lingua, ma per modifiche davvero estetiche al codice, dovresti essere in grado di confrontare i binari compilati prima e dopo una pulizia importante per essere assolutamente sicuro di non averlo inventato.

— John
fonte

Se non includi i tag VC nel file binario (o costruisci informazioni).

— Vatine,

2

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

sei il manager che tenta di stabilire standard di codifica del team
il tuo manager ti ha chiesto di ripulire il codice per aderire agli standard di codifica del team
stai ripulendo il codice da uno sviluppatore che non fa più parte del tuo team per aderire agli standard di codifica del team.

Noterai in tutti i casi che mi riferisco agli standard di codifica del team. Sono un convinto sostenitore di standard di codifica ragionevoli e concordati per il team. Se li hai, lo sviluppatore originale dovrebbe tornare indietro e ripulire il suo codice per aderire agli standard del team, non dovresti farlo alle loro spalle. Se non disponi di standard (e dovresti), non dovresti modificare il codice di un altro membro del team per aderire alle tue filosofie, in particolare alle loro spalle. Ricorda, 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.

— cdkMoose
fonte

"Dietro le loro spalle": questo risale ai problemi psicologici della proprietà del codice (o della guerra del campo di sviluppo).

— rwong,

2

"Codice di altre persone" è un modo interessante di dirlo. Lavoro sul prodotto della mia azienda, compilato dal codice di proprietà della mia azienda, su cui io e il mio team lavoriamo. Non è in alcun modo alle loro spalle fissarlo agli standard mentre ci si lavora. Tuttavia, sono d'accordo sul fatto che la soluzione ideale sia quella di rendere lo sviluppatore originale pulito fino allo standard.

— Caleb Huitt - cjhuitt

@Caleb: diventa difficile se eliminano semplicemente i rifiuti.

— quick_now

Con "codice di altre persone" non intendo la proprietà, intendo qualcosa che hanno scritto e credo che siano ancora responsabili del supporto. In assenza di standard di codifica, se implemento una classe con 1.000 righe di codice e apporti modifiche a 2 righe per correggere un comportamento e riformattare l'intero file, rimarrò molto sorpreso quando apro il file. Come membri di una squadra non dovremmo farlo l'un l'altro. Se esegui il check-in di quel file con una riformattazione completa e non mi dai nemmeno un avvertimento, non è molto amichevole per il team.

— cdkMoose

Nella discussione originale dei PO, ho letto che si tratta di un ambiente senza standard di codifica (o non ben applicato), ecco perché ho risposto in quanto tale. In quell'ambiente, uno sviluppatore non dovrebbe imporre i suoi standard agli altri.

— cdkMoose