È corretto riformattare un altro codice per sviluppatori durante la modifica / aggiunta a un modulo?

Durante lo sviluppo in un'atmosfera di gruppo e l'aggiunta o la modifica di funzionalità in alcune basi di codice. È considerato offensivo o scortese riformattare il precedente codice degli sviluppatori per renderlo conforme agli attuali standard di codifica? Comprendo che gli standard sono cambiati e probabilmente continueranno a cambiare, ma qualcuno di voi si offenderebbe se qualcuno arrivasse e modificasse la formattazione del codice?

Per essere chiari, non sto parlando di cambiare alcuna logica, ma solo fare casino con schede, spazi e così via.

EDIT: Non lo faccio solo per motivi di standard di codifica, mi aiuta a leggere il loro codice e aggiornarlo in modo da poter comprendere appieno la logica che è stata implementata prima di iniziare a modificare le applicazioni critiche.

Penso che sia OK fintanto che gli standard saranno concordati. Una nota di cautela tuttavia; tenere presente se esiste la possibilità che il file venga modificato da altri contemporaneamente. Se rendi la loro unione più difficile solo perché stai modificando la formattazione, non sarai molto popolare.

Sì, il codice dovrebbe appartenere al progetto. Portare il codice su standard aiuterà a ridurre il deficit tecnico del progetto. Se lo stai modificando, sei attualmente responsabile. Per il codice precedente, lo sviluppatore originale potrebbe non essere più sul progetto o avere nuovi compiti.

Quando si esegue questo tipo di modifica, è consigliabile eseguire i test di verifica dopo la riformattazione. Se passano, controlla il codice prima di apportare le modifiche alle funzionalità.

EDIT: nel contesto di questa domanda, è appropriato riformattare secondo lo standard. In assenza di standard, consiglierei di sostenere gli standard e di non riformattarli fino a quando non ci saranno standard per il formato. La riformattazione secondo i gusti / gli standard personali non dovrebbe essere fatta con il codice appartenente al progetto.

Credo che sia sempre una buona pratica riformattare il codice quando si modifica / si aggiunge a un determinato file. Ciò include l'aggiornamento dello stile del codice per riflettere le convenzioni di denominazione appropriate per variabili / metodi e stili di codifica.

Lo faccio sempre. Il vecchio codice dovrebbe essere tenuto agli stessi standard del nuovo codice e se non lo aggiusti mentre ci stai lavorando, nessuno lo farà. Penso che questo valga per la regola del boy scout.

Penso che questa sia una buona pratica e una parte necessaria della manutenzione del codice.

Consiglierei di controllare le modifiche di formattazione in un commit al sistema di controllo versione e le modifiche funzionali in un commit separato per aiutare sia te stesso che gli altri a capire cosa è successo.

Non avrei alcun problema con esso e probabilmente lo apprezzerei ... purché i cambiamenti non siano "religiosi". Per favore, non seguire tutte le mie lezioni e spostare le parentesi graffe sulla prima riga del metodo. Se la formattazione è una cosa legittima "tratti diversi per persone diverse", allora è un po 'fastidioso quando qualcuno entra e impone un formato sul codice che modifichi più frequentemente. Tuttavia, se diventi l'editor principale di quel particolare modulo, apporta le modifiche di formattazione che ritieni più adatte.

Sì. Per favore, "correggi" il codice come ritieni opportuno. Proprio come dicono i programmatori pragmatici nel loro libro The Pragmatic Programmer , nessuna finestra rotta. Se il codice non è all'altezza, lo considero una finestra rotta.

Esistono vari repository che eseguiranno automaticamente la riformattazione al momento del check-in così come piccole cose come cambiare l'associazione CR / LF su get a seconda della piattaforma che ottiene la fonte.

C'è un enorme svantaggio nel fare i tuoi riformattati in quanto il tuo check in delta sarà offuscato da tonnellate di riformattazione e se c'è un problema di regressione diventa più difficile trovare i blocchi di codice offensivi.

Potresti suggerire al tuo leader che, poiché la base di codice è vecchia, dovrebbe essere introdotta dal freddo e riformattata secondo gli standard attuali tutto in una volta, portando a un nuovo brillante futuro per il codice ovunque.

Dato che stai parlando di un problema puramente di "formattazione" (nel senso che non stiamo risolvendo bug ma rendendolo abbastanza simile al tuo standard), penso che dipenda se la persona originale sta ancora mantenendo il codice o meno.

Se l'originatore sta ancora lavorando al progetto, è scortese. Ciò che potrebbe "sembrare" giusto per te non è ciò che "sembrerà" giusto per loro e modificare il codice per motivi di formattazione non è educato. Può anche perdere molto tempo.

Una volta stavo lavorando a un progetto con uno sviluppatore MOLTO possessivo. Nel corso degli anni, ho sviluppato un modo molto metodico di formattare il mio codice che ritengo sia facile da leggere, meno soggetto a errori impliciti e auto-documentazione. Questo ragazzo, d'altra parte, preferiva usare tutte le funzionalità implicite con lunghe righe che si estendevano su 300 caratteri, quindi dovevi avere un monitor da 30 "per leggerlo perché credeva che il conteggio delle linee fosse più importante della leggibilità. Trascorse mezza giornata soffiando attraverso il mio codice cambiandolo al suo "standard preferito" ... mentre stavo ancora sviluppando in parallelo! Sono venuto la mattina dopo per trovare due giorni di lavoro formattati per il suo pasticcio. Era scortese e una perdita di tempo.

Ora se lo sviluppatore non c'è più e hai uno "stile migliore", provalo.

Formatta sempre automaticamente il codice se il tuo IDE può farlo.

• Impedisce alle modifiche manuali di formattazione di ingombrare la cronologia delle versioni a lungo termine
• Il profilo del formatter deve essere concordato tra tutti gli sviluppatori (scegli il valore predefinito? -)
• Rendi la formattazione del codice e l'organizzazione delle importazioni un'abitudine durante il salvataggio di un file

Ad esempio in eclipse, puoi prima eseguire il formatter e organizzare le importazioni per l'intera base di codice. Quindi ricordati di ctrl + alt + f prima di salvare.