¿Debo realizar cambios cosméticos?

Haga commit, con el comentario commit marcado apropiadamente para que sea más fácil ignorarlo cuando hojee una lista de cambios.

No los confirme en la misma operación que un cambio en la funcionalidad. De esa manera, si rompe algo, es más fácil reducir lo que lo rompió y es fácil revertir solo la refactorización si es necesario.

No los confirme junto con correcciones no relacionadas.

Los confirmaría, pero añadiría alguna palabra clave predefinida al mensaje de confirmación. Los mensajes con esta palabra clave podrían ser ignorados al generar registros de cambios.

Podrías usar un prefijo como [cleanup] por ejemplo.

[cleanup] Removed some whitespace
[cleanup] Changed format
Fixed some major bug.
[cleanup] Corrected indentation

En proyectos donde soy el único desarrollador tiendo a hacer este tipo de correcciones junto con otros cambios de código.

En proyectos donde hay un equipo de nosotros tiendo a tratar de cometer este tipo de cambios por su cuenta para que no oscurezcan el 'trabajo real'.

Creo que es importante arreglar todo lo que está 'mal' con una base de código, incluso si son cosas puramente menores como la sangría.

Creo que esto depende de su entorno de trabajo y cómo otros que trabajan en el mismo proyecto quieren lidiar con lo que es probable que difiera.

Por lo tanto, mi sugerencia general sería preguntar a las personas que trabajan con el mismo código y llegar a una directriz para casos como ese. Puede encontrar que a la gente no le importa los check-ins debido a cambios cosméticos o que prefieren vivir con un poco de "sencillez" en lugar de lidiar con registros de cambios desordenados.

Un definitivo una directriz transparente para todos es la mejor manera de abordar estas cuestiones y evitar confusiones en el futuro.

Personalmente, me gusta el código ordenado y no me importaría check-ins debido a cambios puramente cosméticos. Sin embargo, si es solo un poco de espaciado y saltos de línea, probablemente lo dejaría ser y solo lo cambiaría si estuviera trabajando en el mismo archivo de código de todos modos. Yo, a menudo, eliminar y ordenar usando porque me parece confuso si hay un montón de utilizan que no lo hacen sentido, pero eso soy yo.

Hay un par de problemas.

Primero, no hagas cambios en el código porque estás aburrido y no tienes suficientes tareas reales. Si este es el caso, vaya a hablar con su gerente de proyecto y obtenga algunas tareas reales asignadas a usted, algo con valor.

En otras palabras, no vayas cambiando el código por el bien del cambio. Siempre agregue algún valor al código en el proceso.

Ahora, si esos cambios están contribuyendo a hacer que el código sea más fácil de manejar, por usted y por otros, entonces hazlo. Cosas como garantizar que se sigan los estándares de nomenclatura, refactorizar el código crufty, etc. Pero consiga una tarea para él, de modo que su jefe de proyecto pueda decir " Sí, esto es bueno, pase 2 horas en esto y vuelva a mí."

Confirme los cambios cuando haya terminado con ellos. No los lop junto con cualquier tarea real que haya terminado justo antes de ellos, o la siguiente, hará que la fusión de correcciones de errores entre ramas, revisiones de código, y solo la navegación de código general, difícil de seguir.

"Ok, por lo que se corrigió el error 7711, y también cambió alrededor de 100 otros archivos. Bien, entonces, ¿cuál es en realidad la corrección de errores aquí?"

Creo que cuando tienes un equipo de desarrolladores trabajando en el mismo código, lo más importante es acordar un estilo cosmético para el código. Por lo tanto, su primera tarea es tratar de conseguir que todo su equipo se ponga de acuerdo en un estilo de codificación.

Buena suerte.

Una vez que haya hecho eso, realice cambios cosméticos con la frecuencia que desee, para recordar a la gente que se adhiera al estilo.

Hay una gran sección en Code Complete sobre los méritos de los diferentes estilos de codificación. Si puedes hacer que tu equipo lea la sección antes de su reunión de estilo de codificación, podría ayudar a sacarlos a todos de la reunión con vida centrar la discusión.

Definitivamente cometerlos. Si los confirmas junto con cambios de código reales y tienes que revertir esos cambios, entonces pierdes tus correcciones cosméticas.

Idealmente, las confirmaciones deberían ser como transacciones de base de datos: un trozo de código de trabajo relacionado que se puede revertir sin afectar al resto del sistema.

Si los cambios son a cosas que podrían ser de alguna manera controvertidas (posición de los corchetes, por ejemplo), entonces asegúrese de que ha acordado un estilo de código con el resto de su equipo. No solo lo cambie a su propio estilo preferido y luego regístrelo. De lo contrario, alguien más podría volver a cambiarlo y revisar sus cambios, y luego volver a cambiarlo a su manera...

¿Se arreglan estas cosas "menores"? En caso afirmativo, confírmelos. Si no, no.

Realmente, depende de lo que tú y tu equipo consideren importante.

Me gusta comprometerme a menudo. Ciertamente, cada vez que hay un cambio apreciable. Así es fácil. Si empiezas a compartimentar fragmentos de código e intentas confirmar algunos más pronto que tarde, eventualmente olvidarás confirmar algo muy importante.

En resumen: Confirme con frecuencia y SIEMPRE documente el cambio. Cuando hay un gran cambio, etiquétalo.

No cometas solo por cometer. Normalmente los añado para el código en el que estoy trabajando. Por ejemplo, si estoy corrigiendo un error en el método A, me aseguro de hacer todos los cambios cosméticos también.

IMO a ustedes les faltan herramientas de codificación como PMD, JIndent, etc. que se ocupan de estos problemas a medida que codifican. Algunos IDE como Netebeans muestran estos "problemas" como advertencias. Así que no es un cambio aleatorio/personal está siguiendo los estándares.

Envíalos con el próximo gran cambio como nota lateral. Al menos eso es lo que yo haría.