Diff unificado vs. dividido

• Explica las ventajas y desventajas de usar unified diff y split diff en la revisión de código
• unified diff y split diff son adecuados para cambios simples y pequeños
• Para cambios grandes y complejos, ni unified diff ni split diff son ideales
• El autor prefiere revisar la base de código completa en un momento específico, enfocándose en las áreas modificadas recientemente, pero también realizando una revisión general
• El autor propone que la vista de diff ideal mostraría el estado actual del código a la izquierda y, a la derecha, el unified diff de la base de código visible en ese momento junto con cambios resaltados de forma sutil
• Señala que este formato de revisión no está bien soportado por las herramientas existentes, que se enfocan más en revisar el diff que el código real
• El autor usa un flujo de trabajo low-tech para este estilo de revisión, con un script que revisa localmente el pull request. Este script elimina todos los commits del pull request, pero conserva todos los cambios
• Su flujo de trabajo permite navegar y revisar fácilmente los archivos modificados y marcar los hunks revisados, pero carece de sincronización automática entre el búfer de estado y el archivo actualmente abierto en el editor
• El autor quiere una herramienta que facilite revisar código de esta manera, sin necesidad de crear herramientas ad-hoc personalizadas
• El autor también señala que, aunque el texto discute métodos de revisión de código, el objetivo principal de la revisión de código no necesariamente es revisar el código, y presenta enlaces a publicaciones relacionadas sobre este tema

[GN⁺]

Comentarios de Hacker News

• Este artículo analiza las diferencias entre el diff unificado y el diff dividido en la revisión de código.
• Algunos comentaristas sostienen que el tipo de revisión varía según el equipo y el ticket; algunos prefieren una verificación mental como segunda mirada, mientras que otros prefieren una revisión profunda y estructural de la funcionalidad antes del merge.
• Se menciona una herramienta llamada difftastic, que usa diff estructural para resaltar los cambios con mayor nivel de detalle.
• Algunos comentaristas usan scripts con vim para revisar los cambios de un PR abierto para revisión.
• Se destaca la dificultad de la revisión de código en codebases grandes y complejos, y que el problema está más relacionado con la cultura y el intercambio de conocimiento que con las herramientas.
• Se menciona que una de las funciones de GitHub, presionar . para entrar al IDE completo en el navegador, es útil para ver los cambios en el contexto del archivo completo.
• Algunos comentaristas cuestionan la preferencia del autor por eliminar contexto innecesario en el diff dividido, mientras que otros extrañan funciones de otras herramientas como p4merge.
• Se propone usar el VSCode de GitHub en el navegador para ver la vista diff, ya que permite ver el archivo completo y diffs complejos más legibles.
• Meld se sugiere como una herramienta que funciona bien para estos casos de uso.