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

Creo que esto está bien siempre que se acuerden los estándares. Una nota de precaución sin embargo; tenga en cuenta si existe la posibilidad de que otras personas modifiquen el archivo al mismo tiempo. Si hace que su combinación sea más difícil simplemente porque estaba cambiando el formato, no será muy popular.

Sí, el código debe pertenecer al proyecto. Poner el código al nivel estándar ayudará a reducir el déficit técnico del proyecto. Si lo estás modificando, actualmente eres 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 su reformateo. Si se aprueban, verifique el código antes de cambiar sus funciones.

EDITAR: En el contexto de esta pregunta, es conveniente reformatear a estándar. En ausencia de estándares, recomendaría abogar por estándares y no reformatear 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ás 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 que el código nuevo y, si no lo arreglas mientras trabajas en él, nadie lo hará. Creo que esto cuenta bajo la Regla de los Boy Scouts.

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 un compromiso con el sistema de control de versiones y los cambios funcionales en un compromiso separado para que tanto usted como los demás comprendan lo que ocurrió.

No tendría ningún problema con él y probablemente lo apreciarí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 "trazos diferentes para diferentes personas", entonces es un poco molesto cuando alguien ingresa 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, haga los cambios de formato que considere oportunos.

Sí. Por favor "arregla" el código como mejor te parezca. Al igual que los programadores pragmáticos dicen en su libro El programador pragmático , no hay ventanas rotas. Si el código no está a la par, lo considero una ventana rota.

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

Hay un gran inconveniente en hacer tus propios cambios de formato en el hecho de que tu comprobación de los deltas se confunda con toneladas de reformateos y, si hay un problema de regresión, es más difícil encontrar los bloques de códigos ofensivos.

Puede sugerir a su cliente potencial que, dado que la base del código es antigua, debería incorporarse del frío y reformatearse a los estándares actuales de una sola vez, lo que dará lugar a un nuevo y brillante futuro para el código en todas partes.

Ya que estás hablando de un problema puramente de "formateo" (lo que significa que no estamos solucionando errores, sino que lo hacemos ver a tu propio estándar), creo que depende de si la persona original todavía mantiene el código o no.

Si el creador aún está 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 bien del formato no es cortés. También puede perder mucho tiempo.

Una vez estuve trabajando en un proyecto 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 funciones implícitas con líneas largas que se extendían a lo largo de 300 caracteres, 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ó la mitad del día. soplando a través de mi código cambiándolo a su "estándar preferido" ... ¡mientras aún estaba desarrollándome en paralelo! Llegué a la mañana siguiente para encontrar dos días de trabajo con formato para su desastre. Fue grosero y una pérdida de tiempo.

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

Siempre autoformat el código si su IDE puede hacerlo.

• Evita que los cambios de formato manuales impidan su historial de versiones a largo plazo
• El perfil del formateador se debe acordar entre todos los desarrolladores (seleccione el valor predeterminado? -)
• Convertir el código de formato y la organización en 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. Luego recuerde ctrl + alt + f antes de guardar.