¿Está bien volver a formatear otro código de desarrollador mientras se modifica / agrega a un módulo?

Mientras se desarrolla en una atmósfera grupal y agrega o modifica características en alguna base de código. ¿Se considera ofensivo o descortés reformatear el código anterior de los desarrolladores para actualizarlo a los estándares de codificación actuales? Entiendo que los estándares han cambiado, y probablemente continuarán cambiando, pero ¿alguno de ustedes se ofendería si alguien apareciera y cambiara el formato de su código?

Para ser claros, no estoy hablando de cambiar ninguna lógica, solo jugar con pestañas y espacios y demás.

EDITAR: No solo hago esto por el bien de los estándares de codificación, sino que me ayuda a leer su código y actualizarlo para que pueda comprender completamente la lógica que se ha implementado antes de comenzar a modificar aplicaciones críticas.

Creo que esto está bien siempre que se acuerden los estándares. Sin embargo, una nota de precaución; tenga en cuenta si existe la posibilidad de que otros estén modificando el archivo al mismo tiempo. Si hace que su fusión sea más difícil solo porque estaba cambiando el formato, no será muy popular.

Sí, el código debe pertenecer al proyecto. Llevar el código al estándar ayudará a reducir el déficit técnico del proyecto. Si lo está modificando, actualmente es responsable de ello. Para el código anterior, el desarrollador original ya no puede estar en el proyecto o tiene nuevas funciones.

Cuando realice este tipo de cambio, es bueno ejecutar las pruebas de verificación después de volver a formatear. Si se aprueban, verifique el código antes de realizar cambios en sus funciones.

EDITAR: en el contexto de esta pregunta, es apropiado volver a formatear el estándar. En ausencia de estándares, recomendaría abogar por los estándares y no reformatearlos hasta que haya estándares para el formato. El reformateo a gusto / estándares personales no debe hacerse con el código que pertenece al proyecto.

Creo que siempre es una buena práctica refactorizar el código cuando está modificando / agregando a un archivo en particular. Eso incluye actualizar el estilo del código para reflejar las convenciones de nomenclatura adecuadas para variables / métodos y estilos de codificación.

Hago esto todo el tiempo. El código antiguo debe mantenerse con los mismos estándares del nuevo código y si no lo arregla mientras está trabajando en él, nadie lo hará. Creo que esto cuenta bajo la Regla de Boy Scout.

Creo que esta es una buena práctica y una parte necesaria del mantenimiento del código.

Recomendaría verificar los cambios de formato en una confirmación para el sistema de control de versiones y los cambios funcionales en una confirmación separada para ayudarlo a usted y a los demás a comprender lo que sucedió.

No tendría ningún problema con él y probablemente lo agradecería ... siempre y cuando los cambios no sean "religiosos". Por favor, no pase por todas mis clases y mueva las llaves a la primera línea del método. Si el formato es un tipo legítimo de "diferentes trazos para diferentes personas", entonces es un poco molesto cuando alguien entra e impone un formato en el código que edita con más frecuencia. Sin embargo, si se convierte en el editor principal de ese módulo en particular, realice los cambios de formato que considere adecuados.

Si. "Arregle" el código como mejor le parezca. Tal como dicen los programadores pragmáticos en su libro El programador pragmático , no hay ventanas rotas. Si el código no está a la altura, lo considero una ventana rota.

Hay varios repositorios que volverán a formatear automáticamente en el check-in, así como pequeñas cosas como cambiar el emparejamiento CR / LF en get dependiendo de la plataforma que obtenga el origen.

Hay un gran inconveniente en hacer sus propios reformateos, ya que su delta de check-in se ofuscará por toneladas de reformateo y si hay un problema de regresión se hace más difícil encontrar los bloques de código ofensivos.

Puede sugerirle a su líder que, dado que la base del código es antigua, debe ser traída del frío y reformateada a los estándares actuales de una sola vez, lo que lleva a un nuevo y brillante futuro para el código en todas partes.

Dado que está hablando de un problema puramente de "formateo" (lo que significa que no estamos reparando errores sino haciéndolo parecer bonito según su propio estándar), creo que depende de si la persona original aún mantiene el código o no.

Si el autor sigue trabajando en el proyecto, es grosero. Lo que podría "verse" bien para usted no es lo que "se verá" bien para ellos y modificar el código por el simple hecho de formatear no es cortés. También puede perder mucho tiempo.

Estuve trabajando en un proyecto una vez con un desarrollador MUY posesivo. A lo largo de los años, he desarrollado una forma muy metódica de formatear mi código que creo que es fácil de leer, menos propensa a errores implícitos y autodocumentada. Este tipo, por otro lado, prefería usar todas las características implícitas con líneas largas que se extendían a 300 caracteres de ancho, por lo que tenía que tener un monitor de 30 "para leerlo porque creía que el recuento de líneas era más importante que la legibilidad. Pasó medio día revisé mi código y lo cambié a su "estándar preferido" ... ¡mientras yo todavía estaba desarrollando en paralelo! Vine a la mañana siguiente para encontrar dos días de trabajo formateados para su desorden. Fue grosero y una pérdida de tiempo.

Ahora, si el desarrollador se ha ido y tienes un "mejor estilo", hazlo.

Siempre formatee el código automáticamente si su IDE puede hacerlo.

• Evita que los cambios de formato manual desordenen su historial de versiones a largo plazo
• El perfil del formateador debe ser acordado entre todos los desarrolladores (¿elegir el predeterminado? -)
• Haga que el código de formato y la organización de las importaciones sean un hábito al guardar un archivo

Por ejemplo, en eclipse, primero puede ejecutar el formateador y organizar las importaciones para todo el código base. Entonces recuerde ctrl + alt + f antes de guardar.