¿Hay justificación para dejar los marcadores de conflicto en el código registrado?

14

Considera marcadores de conflicto. es decir:

<<<<<<< branch
blah blah this
=======
blah blah that
>>>>>>> HEAD

En el caso particular que me ha motivado a publicar esta pregunta, el miembro responsable del equipo acababa de completar una fusión desde el centro hacia nuestra sucursal y, en algunos casos, los había dejado, como comentarios, como una especie de documentación sobre lo que Acababa de ser resuelto. Lo dejó en un estado compilado, pasando las pruebas, así que no es tan malo como se podría pensar.

Aunque instintivamente, realmente me opuse a esto, sin embargo, como los demonios se defienden, puedo ver por qué pudo haberlo hecho:

  • porque destaca a otros desarrolladores de equipos lo que ha cambiado como resultado de la fusión.
  • porque aquellos que son más expertos con las piezas de código particulares pueden abordar las preocupaciones ilustradas en los comentarios para que no tenga que adivinar.
  • porque la combinación ascendente es un dolor correcto y puede ser difícil justificar el tiempo para resolver todo bien y por completo, por lo que es necesario un aviso FIXME semi-completo, así que, ¿por qué no usar el conflicto original como un comentario para documentar esto? .

Mi objeción fue instintiva, pero me gustaría poder justificarla racionalmente, o ver mi posición más sabiamente. ¿Alguien puede darme algunos ejemplos o incluso experiencias en las que la gente haya tenido un mal momento con otra persona haciendo esto y / o razones por las que es una mala práctica (o puede jugar al defensor del diablo y apoyarlo)?

Mi propia preocupación inmediata era que claramente hubiera sido molesto si hubiera estado editando uno de los archivos en cuestión, hubiera eliminado los cambios, hubiera tenido conflictos reales, pero también hubiera eliminado los comentados. Entonces habría tenido un archivo muy desordenado de hecho. Afortunadamente eso no sucedió.

    
pregunta Benedict 25.10.2011 - 19:38
fuente

4 respuestas

27

Esto está claramente mal. El trabajo del sistema de control de versiones es realizar un seguimiento de los cambios, y es el trabajo de las herramientas de diferencias mostrar qué ha cambiado como resultado de la combinación. Debería haber un comentario en el registro de confirmación, y tal vez en el código, que explique qué se cambió y por qué. Sin embargo, en mi humilde opinión, dejar los marcadores de conflicto como comentarios es lo mismo que dejar un código muerto alrededor.

    
respondido por el Dima 25.10.2011 - 20:04
fuente
5

He tenido un problema similar con algunos códigos, ya sea por comentarlos (lo que de alguna manera es similar a tu caso) o por ser movido a un método que no se llama en ningún lado. Cuando se les preguntó por qué las personas hacen esto, la respuesta fue que se sienten un poco más seguros cuando todavía tienen algunos bloques de código. El argumento contrario más obvio es que es un trabajo VCS y no el suyo. Sin embargo, también hay otro aspecto. Cuando alguien más está leyendo el código mientras aprende o hace cambios, es probable que ese comentario lo desvíe del tema. Definitivamente lo leerá y tal vez dedique algo de tiempo a comprender por qué está aquí y qué correlación posible tiene con su trabajo actual. Como un marcador de conflicto es un signo de un conflicto, que ya se ha resuelto, esto es sin duda una pérdida de tiempo.

    
respondido por el Jacek Prucia 25.10.2011 - 21:20
fuente
4

Creo que los comentarios deben referirse al código que está allí, no al código que ha estado allí en el pasado, ni a los eventos que sucedieron al código en el pasado, ni al código que existió en un universo paralelo (otra rama ) en el pasado. Dejar los marcadores en la forma en que lo hizo el miembro de su equipo crea al menos tres problemas:

  1. El código original probablemente era algo como blah blah null , y el informe del error decía "No se puede usar nulo allí, usar esto o aquello, o lo que sea". Así que dos personas corrigieron el error de forma independiente y, cuando se fusionaron las correcciones, surgió el conflicto. Ahora el comentario no documenta cuál fue el problema ni lo que reparó la solución, sino solo que hubo dos soluciones diferentes en algún momento en el pasado. Eso no es de mucha ayuda. Un comentario como //blah blah needs a non-null argument al menos daría una indicación de lo que cambió (e incluso esa información está más fácilmente disponible en el comentario de confirmación del sistema de control de versiones).
  2. Es posible que la versión fusionada no parezca una de las líneas originales. Tal vez si quieres que bla bla tome esto y aquello, la forma correcta es blah blah (this,that) o incluso algo más complicado. En ese caso, dejar el mensaje de conflicto como un comentario seguramente confundirá a cualquiera que intente leer el código más adelante.
  3. La mayoría de los sistemas de control de versiones le dan acceso al historial del proyecto. Por ejemplo, puedo hacer clic derecho en un archivo en eclipse (con svn), decir "Mostrar historial ..." y luego decir "Comparar actual con ..." y obtener una ventana de diferencias que resalta las diferencias. Esa información es la forma es más fácil de asimilar si los puntos destacados de diff contienen las diferencias reales, y no los comentarios que las rodean. Cada cambio no funcional en el código hace que sea más difícil leerlo.
respondido por el wallenborn 26.10.2011 - 15:16
fuente
-1
  

¿Qué tan molestos son los marcadores de conflicto en el código registrado?

Muy molesto.

    
respondido por el Apocalisp 26.10.2011 - 18:29
fuente

Lea otras preguntas en las etiquetas