Va bene riformattare un altro codice per sviluppatori modificando / aggiungendo a un modulo?

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

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

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

EDIT: nel contesto di questa domanda, la riformattazione dello standard è appropriata. In assenza di standard, raccomanderei di sostenere gli standard e non di riformattare fino a quando non ci saranno standard per il formato. La riformattazione ai gusti / standard personali non dovrebbe essere eseguita con il codice appartenente al progetto.

Credo che sia sempre una buona pratica per il refactoring del codice quando si modifica / si aggiunge a un particolare 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 non lo farà nessuno. Penso che questo valga sotto la regola del Boy Scout.

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

Consiglierei di verificare le modifiche di formattazione in un commit al sistema di controllo della versione e le modifiche funzionali in un commit separato per aiutare te stesso e 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 passare attraverso tutte le mie classi e spostare le parentesi graffe sulla prima riga del metodo. Se la formattazione è legittima per "tipo di tratti diversi per persone diverse", allora è un po 'fastidioso quando qualcuno entra e impone un formato sul codice che si modifica più di frequente. Tuttavia, se diventi l'editor principale di quel particolare modulo, allora apporta le modifiche di formattazione che ritieni opportune.

Sì. Per favore "aggiusta" il codice come meglio credi. 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.

Ci sono vari repository che eseguiranno automaticamente la riformattazione al momento del check-in così come piccole cose come cambiare l'accoppiamento CR / LF in base alla piattaforma che ottiene l'origine.

C'è un enorme svantaggio nel fare i tuoi riformatt in quanto i tuoi delta di check in saranno offuscati da tonnellate di riformattazione e se c'è un problema di regressione diventa più difficile trovare i blocchi di codice incriminati.

Potresti suggerire al tuo lead che dal momento che la base del codice è obsoleta, dovrebbe essere portata dal freddo e riformattata secondo gli attuali standard tutto in una volta, portando a un nuovo futuro brillante per il codice ovunque.

Dato che stai parlando di un problema puramente di "formattazione" (il che significa che non stiamo correggendo i bug ma lo rendiamo piuttosto simile al tuo standard), penso che dipenda se la persona originale mantiene o meno il codice.

Se il creatore sta ancora lavorando al progetto, è maleducato. Ciò che potrebbe "sembrare" giusto per te non è ciò che "guarderà" direttamente a loro e modificare il codice per motivi di formattazione non è educato. Può anche perdere un sacco di tempo.

Stavo lavorando a un progetto una volta con uno sviluppatore MOLTO possessivo. Nel corso degli anni, ho sviluppato un metodo molto metodico per formattare il mio codice che ritengo sia facile da leggere, meno incline agli errori impliciti e autodocumentante. Questo tizio, d'altra parte, preferiva usare tutte le caratteristiche implicite con lunghe righe che si estendevano per 300 caratteri, quindi dovevi avere un monitor da 30 "per leggerlo perché riteneva che il conteggio delle linee fosse più importante della leggibilità. sfogliando il mio codice cambiandolo al suo "standard preferito" ... mentre mi stavo ancora sviluppando in parallelo! Sono venuto la mattina dopo per trovare due giorni di lavoro che sono stati formattati per il suo casino. È stato scortese e una perdita di tempo.

Ora se lo sviluppatore è sparito e hai uno "stile migliore", fallo.

Crea sempre autoformat il codice se il tuo IDE può farlo.

• Impedisce le modifiche di formattazione manuali dalla confusione della cronologia delle versioni a lungo termine
• Il profilo del formatter deve essere concordato tra tutti gli sviluppatori (scegli l'impostazione predefinita? -)
• Rendi il codice di formattazione e l'organizzazione delle importazioni un'abitudine quando salvi un file

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