Atlasingeniería

Code review en la prácticaLos comentarios que vuelven siempreTema 5

Ruido del editor: comillas, comas y reindentados que tapan el diff

Cincuenta líneas modificadas de las cuales dos importan. El editor cambió comillas, agregó comas finales y reindentó un bloque, y ahora el revisor tiene que encontrar el cambio real entre el ruido.

Abrís un archivo, tocás dos líneas, guardás. El editor —con su configuración, distinta de la del resto del equipo— cambia comillas dobles por simples en todo el archivo, agrega comas finales, reindenta un bloque que estaba con otra sangría.

El diff muestra cincuenta líneas. Dos son tuyas. El revisor no sabe cuáles.

Por qué no es un detalle

ConsecuenciaCómo se ve
La review se vuelve superficialEl revisor filtra a ojo y aprueba lo que parece formato; un cambio de lógica escondido pasa
El historial se rompeLa herramienta que muestra quién cambió cada línea apunta al reformateo, no a quien escribió la lógica
Los conflictos se multiplicanDos ramas que reformatearon distinto el mismo archivo chocan en líneas que ninguna de las dos quiso tocar
Se discute lo que no importaMedia review sobre comillas, cero sobre el caso que falta
El segundo es el que más molesta meses después, investigando cuándo se introdujo un comportamiento.

Hay una versión peor: el reformateo accidental con un cambio de comportamiento adentro. No hace falta mala intención para que pase; alcanza con que nadie pueda revisar cincuenta líneas de ruido con atención.

La solución no es pedir cuidado

Esto no se arregla con disciplina individual, porque cada persona tiene su editor configurado como le gusta. Se arregla sacando la decisión de las manos de todos.

Lo que lo elimina de raíz

  1. Un formateador con configuración en el repositorio. El formato deja de ser una opinión y pasa a ser una salida determinística: todos guardan y el resultado es idéntico.
  2. Verificación en el pipeline. El formato se chequea automáticamente; nadie comenta comillas en una review nunca más.
  3. Configuración del editor versionada. Fin de línea, sangría y codificación acordados en un archivo del proyecto, para que el editor de cada uno se alinee solo.
  4. Formatear sólo lo que se toca, si el proyecto todavía no está formateado por completo. La mayoría de las herramientas permite limitar el formateo a las líneas modificadas.

Los otros ruidos del diff

El formateo no es el único. Hay cuatro que aparecen seguido y tienen el mismo efecto.

Qué más ensucia un cambio

  1. Fin de línea distinto. Un equipo con sistemas operativos mezclados y sin normalización produce diffs donde el archivo entero figura como modificado.
  2. Archivos generados versionados. Un bloqueo de dependencias o un artefacto de construcción que cambia por completo en cada instalación.
  3. Reordenar imports automáticamente con una regla que no comparte el resto del equipo.
  4. Renombres masivos mezclados con lógica, que es el caso que hace que un bug pase inadvertido.

Antes de seguir, predecí

Necesitás renombrar una variable usada en veinte archivos y además arreglar un bug en uno de ellos. ¿Cómo lo entregás?

Encontrar las dos líneas que importan

src/checkout/summary.ts+8−8

Hay 4 problemas en este cambio. Tocá la línea donde creas que está.

@@ -1,16 +1,16 @@
1
2
1
2
33
4
5
6
7
8
9
4
5
6
7
8
9

Dieciséis líneas cambiadas, dos que importan, y una de las dos es un arreglo de facturación.

Cómo se elimina de raíz

Cierre

Autoevaluación

¿Lo entendiste?

¿Cuál es el efecto más peligroso de un diff con mucho ruido de formato?
¿Cómo se elimina de raíz la discusión sobre comillas y sangrías en las reviews?