Devo eseguire modifiche estetiche?

Question

Ci sono modifiche di stile di codifica minori che spesso desidero eseguire il commit al controllo del codice sorgente, ma ora il registro delle modifiche è pieno di quelle modifiche che non influiscono sulla funzionalità del codice.

Cosa devo fare la prossima volta che devo sistemare le cose minori come:

• Rimuovere e ordinare usings (in .NET, le importazioni in pitone, include in C++)
• indentazione corretta, la spaziatura e la linea pause

Answer 1

Se si sta modificando il file di codice, non vedo davvero perché non si voglia eseguire il commit e condividere tali modifiche. Se non lo fai, corri il rischio che qualcun altro lo risolva e poi si scontrino con il tuo.

Se non sono modifiche che altri utenti desiderano nella base di codici, forse dovresti chiederti perché stai trascorrendo del tempo a scriverle.

Answer 2

Queste cose "minori" risolvono? Se sì, impegnali. Se no, non farlo.

In realtà, dipende da ciò che voi e il vostro team considerate importanti.

Answer 3

Impegnati con il prossimo grande cambiamento come sidenote. Almeno questo è quello che farei.

Answer 4

Non impegnarli insieme con correzioni non correlate.

Li impegna, ma aggiungo alcune parole chiave predefinite al messaggio di commit. I messaggi con questa parola chiave potrebbero quindi essere ignorati durante la generazione dei log delle modifiche.

È possibile utilizzare ad esempio un prefisso come [cleanup].

[cleanup] Removed some whitespace 
[cleanup] Changed format 
Fixed some major bug. 
[cleanup] Corrected indentation 

Answer 5

Su progetti in cui sono l'unico sviluppatore, tendo a fare questo tipo di correzioni insieme ad altre modifiche al codice.

Sui progetti in cui c'è una squadra di noi, tendo a provare a commettere questi tipi di modifiche in modo da non oscurare il "vero lavoro".

Ritengo che sia importante correggere tutto ciò che è "sbagliato" con un codebase anche se si tratta di cose puramente secondarie come l'indentazione.

Answer 6

Eseguire il commit, con il commento di commit contrassegnato in modo appropriato per semplificare l'ignizione quando si sfoglia un elenco di modifiche.

Non impegnarli nella stessa operazione di un cambio di funzionalità. In questo modo, se si interrompe qualcosa, è più facile restringere ciò che lo ha rotto ed è facile ripristinare solo il refactoring, se necessario.

Answer 7

Mi piace commettere spesso. Certamente ogni volta che c'è un cambiamento apprezzabile. È facile in questo modo. Se inizi a compartimentare i frammenti di codice e provi a eseguire il commit prima o poi, alla fine dimenticheresti di commettere qualcosa di molto importante.

In breve: commit spesso e SEMPRE documenta la modifica. Quando c'è un cambiamento ENORME, taggalo.

Answer 8

Penso che questo dipenda dal vostro ambiente di lavoro e da come gli altri che lavorano sullo stesso progetto vogliono gestire ciò che è probabile che differisca.

Quindi, il mio suggerimento generale sarebbe quello di chiedere alle persone che lavorano con lo stesso codice e di elaborare una linea guida per casi come quello. Potresti scoprire che le persone non si occupano dei check-in a causa di modifiche estetiche o che preferiscono vivere con un po 'di "non redditività" piuttosto che occuparsi di registri di modifiche ingombranti.

Una linea guida definitiva che sia trasparente per tutti è il modo migliore per affrontare queste domande ed evitare confusione in futuro.

Personalmente, mi piace riordinare il codice e non mi dispiacerebbe effettuare il check-in a causa di cambiamenti puramente estetici. Tuttavia, se è solo un po 'di spaziatura e interruzioni di riga, probabilmente lo lascerei e lo cambierei solo se stavo lavorando sullo stesso file di codice. Spesso rimuovo e classifico gli usi perché trovo confuso se ci sono un sacco di usi che non hanno senso, ma sono solo io.

Answer 9

Definitivamente li commettono. Se li si commette insieme alle modifiche del codice reale e si devono ripristinare tali modifiche, si perdono le correzioni di cosmetici.

Idealmente, i commit dovrebbero essere come le transazioni del database: una porzione di codice di lavoro correlato che può essere ripristinata senza influire sul resto del sistema.

Answer 10

C'è un paio di problemi.

In primo luogo, non apportare modifiche al codice perché sei annoiato e non ha abbastanza attività reali. Se questo è il caso, vai a parlare con il tuo project manager e ottieni alcuni compiti reali assegnati a te, qualcosa con valore.

In altre parole, non cambiare il codice per il cambiamento. Aggiungi sempre qualche valore al codice nel processo.

Ora, se tali modifiche stanno contribuendo a rendere il codice più facile da gestire, da parte dell'utente e di altri, quindi eseguirli. Cose come assicurare che gli standard di naming vengano seguiti, codice di refifficazione, ecc. Ma prendi un compito, in modo che il tuo project manager possa dire "Sì, è buono, passa 2 ore a questo e torna da me".

Confermare le modifiche quando hai finito con loro. Non tritarli insieme a qualsiasi compito reale tu abbia appena terminato prima di loro, o il prossimo, farà unire correzioni di bug tra rami, revisioni di codice e solo una navigazione di codice generale, difficile da seguire.

"Ok, quindi hai corretto il bug 7711, e anche cambiato circa altri 100 file. Bello, quindi qual è in realtà il bugfix qui?"

Answer 11

Penso che quando si ha un team di sviluppatori che lavora sullo stesso codice, la cosa più importante è concordare uno stile cosmetico per il codice. Quindi, il tuo primo compito è cercare di convincere l'intero team a concordare uno stile di codifica.

Buona fortuna.

Una volta eseguita questa operazione, apportare modifiche estetiche tutte le volte che si desidera, per ricordare alle persone di attenersi allo stile.

C'è una grande sezione in Codice completo sui meriti dei diversi stili di codifica. Se riesci a convincere la tua squadra a leggere la sezione prima della riunione sullo stile di codifica, potrebbe aiutare a far fuoriuscire tutti dalla riunione in vita.

Answer 12

Se i cambiamenti riguardano cose che potrebbero essere in qualche modo controverse (posizione delle parentesi, ad esempio), assicurati di aver concordato uno stile di codice con il resto del tuo team. Non cambiarlo semplicemente con il tuo stile preferito, quindi controllalo. In caso contrario, qualcun altro potrebbe cambiarlo e controllarne le modifiche, quindi lo cambierai a modo tuo ...

Answer 13

Non commettere solo per motivi di impegno. Di solito li aggiungo per il codice su cui sto lavorando. Ad esempio, se correggo un bug nel metodo A, assicurati di apportare anche tutte le modifiche estetiche.

IMO voi ragazzi mancano strumenti di codifica come PMD, JIndent, ecc. Che si occupano di questi problemi durante la codifica. Alcuni IDE come Netebeans mostrano questi "problemi" come avvertimenti. Quindi non è un cambiamento casuale/personale seguire gli standard.