La frase sonaba a SQL de verdad, y estaba mal
Reviso código de proyectos que no son míos, y hace poco me tocó un cambio que afinaba algo delicado: cuántas unidades puede consumir un usuario antes de que el sistema le corte el paso. El comentario que acompañaba el cambio decía, con la seguridad de quien sabe de lo que habla, algo así: «si el cupo del usuario es nulo, el cálculo del mínimo da nulo, la comparación da nulo, y la condición sale falsa — el sistema falla cerrado». Debajo, una prueba automática confirmaba exactamente esa frase: cupo nulo, cero acceso. Todo en verde.
Llevo tiempo sin fiarme de un verde sin mirar qué prueba exactamente, así que en vez de dar la frase por buena levanté una base de datos real del mismo motor y escribí la comparación yo mismo, con datos de mentira: un cupo nulo contra un número cualquiera. La respuesta no fue nula. Fue el número. En ese motor, la función que se usaba para calcular el mínimo simplemente ignora los valores nulos si hay al menos uno que no lo es — así que un cupo sin definir no bloqueaba nada, dejaba pasar sin límite. Justo lo contrario de lo que el comentario prometía, y de lo que la aplicación necesitaba que fuera cierto para no dejar pasar de más a quien no tuviera cupo asignado.
La prueba automática seguía en verde, y ahí estaba el segundo hallazgo: no pasaba porque el código estuviera bien, pasaba porque el simulador de base de datos que usaba esa prueba modelaba mal esa función — le había puesto el comportamiento de un motor distinto, uno donde sí falla cerrado. La prueba no comprobaba el sistema real: comprobaba una copia del sistema real con una pieza cambiada por otra que se le parecía. Y esa copia decía que sí.
No llegó a producción — por otro camino, la columna nunca podía quedar vacía de verdad —, así que nadie estaba en peligro. Pero eso no fue lo que me hizo devolver el cambio. Lo que me hizo devolverlo es que ese comentario, y esa prueba en verde, iban a quedar ahí para el siguiente que tocara ese código, contándole con toda la confianza del mundo cómo se comporta una función que no se comporta así. Un código que hace lo correcto por casualidad y una frase que explica mal por qué lo hace son peores juntos que un error a secas: el error se nota, la explicación falsa se hereda.
Lo que me llevo no es desconfiar del código — el código, de hecho, estaba bien. Es desconfiar de la prosa que lo acompaña con la misma sospecha, o más, que del propio código, porque la prosa nunca falla en rojo. Un comentario mal escrito no rompe nada al arrancar. Solo espera a que alguien lo lea, se lo crea, y construya la siguiente pieza encima.