¿Debo realizar cambios cosméticos?

Existen cambios menores en el estilo de codificación que a menudo deseo comprometer con el control de origen, pero ahora el registro de cambios está lleno de esos cambios que no afectan la funcionalidad del código.¿Debo realizar cambios cosméticos?

¿Qué debería hacer la próxima vez que tengo que arreglar las cosas menores, como:

Quitar y ordenar usings (en .NET, las importaciones en pitón, incluye en C++)
sangría correcta, el espaciamiento y la línea saltos

Fuente

2010-01-12 Jader Dias

tal vez esto debería obtener la etiqueta "subjetiva"? –

Comprométete a menudo, para eso están las herramientas scm. En mi opinión, de ninguna manera el archivo de registro scm debe ser visto como una etiqueta propia de ChangeLog –

añadida como "subjetiva". –

Si está cambiando el archivo de código, realmente no veo por qué no desea comprometer y compartir esos cambios. Si no lo hace, corre el riesgo de que alguien más lo arregle y luego colisione con el suyo.

Si no se trata de cambios que otros usuarios deseen en la base de código, quizás deba preguntarse por qué pasa el tiempo escribiendo.

Fuente

2010-01-12 13:15:46

Buen punto. . . –

Y si no solo vas a molestar a todos con interminables espacios en blanco/cosméticos diffs. –

@Dominic ahora usted dice que no debería ... –

¿Son estas soluciones "menores" las soluciones? Si es así, compromételos. Si no, no.

Realmente, depende de lo que usted y su equipo consideren importante.

Fuente

2010-01-12 13:14:56

-5

Comételos con el siguiente gran cambio como nota al margen. Al menos eso es lo que haría.

Fuente

2010-01-12 13:15:08 Bobby

+12

-1 - eso hará imposible que funcione lo que realmente ha cambiado en tu gran cambio. Los cambios de espacios en blanco/cosméticos siempre deben estar separados, por lo que los cambios reales son más fáciles de ver. –

Pero quizás fusionar una corrección de errores simple en otra rama, una versión lanzada, puede ser ruidosa porque el conjunto de cambios contiene muchos cambios no relacionados. –

@Dominic, Lasse: Ustedes tienen razón ... echo de menos que también existe el conjunto de cambios para cada compromiso, que estaría atestado de cambios en el espacio en blanco ... lo siento. – Bobby

No los cometer junto con arreglos no relacionados.

Lo confirmaría, pero agregaré una palabra clave predefinida al mensaje de confirmación. Los mensajes con esta palabra clave podrían ignorarse al generar registros de cambios.

Puede usar un prefijo como [cleanup] por ejemplo.

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

Fuente

2010-01-12 13:17:04

[cosmetic] también es adecuado como palabra clave, indica que es una limpieza que no realiza ningún cambio funcional. – florisla

En proyectos donde soy el único desarrollador que tienden a hacer este tipo de planos fijos, junto con otros cambios en el código.

En proyectos donde hay un equipo de nosotros, tiendo a intentar y cometer este tipo de cambios por sí solos 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 se trata de elementos menores como la sangría.

Fuente

2010-01-12 13:17:18

Compromételos, con el comentario de compromiso marcado adecuadamente para que sea más fácil ignorarlo al pasar por una lista de cambios.

No los compromise en la misma operación como un cambio de funcionalidad. De esta forma, si rompes algo, es más fácil reducir lo que se rompió y es fácil revertir solo la refactorización si es necesario.

Fuente

2010-01-12 13:17:27 moonshadow

Esto es realmente importante. Aceptar los cambios en el espacio en blanco junto con los cambios funcionales es peligroso. Hace que sea difícil para las personas descubrir lo que realmente cambió. Y, como todos los demás dijeron, asegúrese de que los cambios cosméticos sean fácilmente reconocibles a partir de sus mensajes de confirmación. (Usas los mensajes de confirmación en cada confirmación, ¿verdad?) – mcv

me gusta comprometerme a menudo. Ciertamente, cada vez que hay un cambio apreciable. Es fácil de esa manera. Si comienzas a compartimentar los fragmentos de código y tratas de comprometerlos más pronto que tarde, eventualmente te olvidarás de cometer algo muy importante.

En resumen: comprométase a menudo y documente SIEMPRE el cambio. Cuando hay un cambio ENORME, márquelo.

Fuente

2010-01-12 13:19:24

Creo que esto depende de su entorno de trabajo y de cómo otras personas que trabajan en el mismo proyecto desean ocuparse de aquello que probablemente difiera.

Por lo tanto, mi sugerencia general sería preguntar a las personas que trabajan con el mismo código y elaborar una guía para casos como ese. Es posible que descubra que a las personas no les molesta el check-in debido a cambios cosméticos o que preferirían vivir con un poco de "falta de pretensiones" en lugar de lidiar con registros de cambios desordenados.

Una directriz definitiva que sea transparente para todos es la mejor manera de tratar estas cuestiones y evitar confusiones en el futuro.

Personalmente, me gusta el código ordenado y no me importaría el check-in debido a cambios puramente cosméticos. Sin embargo, si solo se trata de un poco de espacio y saltos de línea, probablemente lo dejaría solo y solo lo cambiaría si estuviera trabajando en el mismo archivo de código de todos modos. A menudo elimino y clasifico los usos porque me resulta confuso si hay un montón de usos que no tienen sentido, pero así soy yo.

Fuente

2010-01-12 13:19:38

Definitivamente cometerlos. Si los compromete con cambios de código reales y tiene que deshacer esos cambios, entonces pierde sus correcciones estéticas.

Idealmente, las confirmaciones deben ser como las transacciones de la base de datos: un fragmento de código de trabajo relacionado que se puede revertir sin afectar el resto del sistema.

Fuente

2010-01-12 13:20:52

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, ve a hablar con tu gerente de proyecto y consigue algunas tareas reales asignadas a ti, algo con valor.

En otras palabras, no vaya a cambiar el código por el bien del cambio. Siempre agregue algo de valor al código en el proceso.

Ahora, si esos cambios están contribuyendo a que el código sea más fácil de manejar, usted y otros, entonces hágalo. Cosas como asegurar el cumplimiento de los estándares de nomenclatura, refactorizar el código seguro, etc. Pero obtenga una tarea para que su jefe de proyecto pueda decir "Sí, esto es bueno, dedique 2 horas a esto y vuelva a consultarme".

Confirme los cambios cuando haya terminado con ellos. No los junte con la tarea real que haya terminado justo antes de ellos, o la próxima, hará que la fusión de las correcciones de errores entre sucursales, revisiones de código y solo la exploración general de códigos, sea difícil de seguir.

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

Fuente

2010-01-12 13:24:37

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 intentar que todo su equipo acuerde un estilo de codificación.

Buena suerte.

Una vez que haya hecho eso, realice cambios cosméticos tantas veces como desee, para recordar a las personas que se adhieran al estilo.

Hay una gran sección en Code Complete sobre los méritos de los diferentes estilos de codificación. Si puede lograr que su equipo lea la sección anterior a 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.

Fuente

2010-01-12 13:27:20

Estoy casi completamente de acuerdo. Primero, escriba un estilo de codificación escrito que todos estén de acuerdo. Sin embargo, realizar cambios cosméticos con frecuencia no lo hará popular entre otros desarrolladores de su equipo. En cambio, prefiero hacer una limpieza completa del estilo de codificación y confirmarlo de una vez. Puede haber puntos de tiempo específicos en el ciclo de producción en los que se puede hacer una limpieza de este tipo. –

@nikai: buen punto. Creo que algunos commits repetidos desde el principio pueden ahorrar trabajo de limpieza de código repetido más adelante (la gente tiene que aprender de alguna manera), pero por supuesto hay muchas veces dentro del ciclo de producción cuando el estilo de codificación no es la prioridad. –

Si los cambios se refieren a cosas que pueden ser de alguna manera controvertidas (por ejemplo, la posición de los corchetes), asegúrese de haber acordado un estilo de código con el resto de su equipo. No lo cambie solo a su estilo preferido y luego instálelo. De lo contrario, alguien más podría volver a cambiarlo y comprobar sus cambios, luego lo cambiará de nuevo a su manera ...

Fuente

2010-01-12 14:30:42 MTEd

No confirme solo por el bien de comprometerse. Normalmente los agrego 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 ustedes están perdiendo herramientas de codificación como PMD, JIndent, etc. que se ocupan de este problema mientras codifica. Algunos IDE como Netebeans muestran estos "problemas" como advertencias. Entonces, no es un cambio aleatorio/personal siguiendo los estándares.

Fuente

2010-01-12 14:35:35 javydreamercsw

¿Debo realizar cambios cosméticos?

Respuesta

Cuestiones relacionadas