¿Se comete un error al cambiar el formato de origen?

Question

¿Es una práctica aceptada comprometerse incluso cuando solo está cambiando cosas como el espacio en blanco, el formato del código, etc.?

Answer 1

Sí. Si necesita hacer cambios en el espacio en blanco, hacerlo en una confirmación separada que contenga solo este tipo de limpieza es la mejor práctica. Esto evita problemas al tratar de ver qué parte de una diferencia gigante es el cambio real del código, y qué parte son los cambios de formato (cosméticos).

Dicho esto, usted debe tratar de mantener este tipo de cambios al mínimo, y sólo lo hacen en absoluto cuando es necesario y compatible con cualquier estándares de codificación se utilizan en su empresa/comunidad/proyecto/etc

Answer 2

Sí, siempre que exista cierta coherencia entre los distintos repositorios involucrados, de lo contrario se dificultaría mucho la fusión debido al conflicto debido al formateo.
Al menos una confirmación por separado ayuda a identificar la fuente real del posible conflicto durante esa fusión futura.

Si no es "su" código (es decir, algún otro repositorio con algún otro estándar de formato tendrá que fusionar lo que está haciendo), puede aprovechar el git attribute filter driver y su mecanismo de borrado/limpieza.

^{(Fuente: Pro Git book: Customizing Git - Git Attributes)}

Se podría aplicar su formato de al código durante el paso de borrones y volver a aplicar el estándar de formato común durante la etapa de limpieza.

Answer 3

Sí! ¡Sí! Como un compromiso separado, por favor! (Este tipo de ediciones tienden a tocar una gran cantidad de código, y la gente necesita saber si un commit/changeset/patch/whatever está allí por razones de reformateo, sin cambios destinados al código real).

Answer 4

G 'día,

Sí. Pero, por favor hacerlo como un dedicado comprometerse con un mensaje que indica que usted ha

• formato cambiado,
• ejecutar el código a través de un formateador de código, por ejemplo, Perltidy, con una nota acerca de la configuración utilizada realmente,
• etc.

nada peor que tener cambios de formato combinado con cambios funcionales así haciendo diferencias entre las versiones proporciona una pobre relación S/N!

Como un aparte, me pregunto por qué estás haciendo cambios en el formato del código existente. ¡No debería haberse registrado si estaba mal formateado en primer lugar!

No hay nada peor que trabajar con alguien que pasa por el cambio de fuente bien formateado por ninguna otra razón que no sea:

• piensan llaves pertenecen en la línea del "if", o
• que no les gusta "abrazado vigilara", o
• etc.
• etc.

Tales expresiones religiosas de " el único estilo verdadero "usualmente desmiente la falta de experiencia y experiencia en la codificación al trabajar en equipo".

HTH

aplausos,

Answer 5

Las respuestas ya que aquí hacen un buen trabajo de explicar por qué puede ser un problema para confirmar los cambios de formato. Creo que una solución sería la compatibilidad con el editor para permitir que uno vea el código formateado al mismo tiempo que minimiza los cambios de formato al guardar el archivo.

he hecho una pregunta relacionada acerca de esto en ...

• Is there a text editor that will "pretty print" for display without changing the underlying text?

Si cualquier buenas respuestas llegan hasta allí, los espectadores de esta cuestión también puede estar interesado.