06.10.2026 · Signal Titans Editorial

La regla de Brian Kernighan para un código mejor: si es demasiado listo, no podrás depurarlo

Brian Kernighan hablando ante un micrófono durante Vintage Computer Festival East en 2025.

Brian Kernighan pasó décadas rodeado de algunos de los sistemas de software más influyentes de la historia. Una de las reglas a las que volvió una y otra vez era casi incómodamente simple: si tu código es demasiado listo, quizá tú mismo no seas lo bastante listo para arreglarlo después.

Brian Kernighan trabajó 30 años en Bell Labs, dentro del grupo de computación vinculado al desarrollo de Unix, y más tarde se incorporó a la facultad de informática de Princeton. Fue coautor de The C Programming Language con Dennis Ritchie y escribió algunos de los libros más influyentes sobre estilo de programación, herramientas y lenguajes.

Para alguien con ese currículum, su consejo sobre código es sorprendentemente poco glamuroso.

“Depurar es el doble de difícil que escribir el código por primera vez.”

El resto de la idea cae por su propio peso: si utilizas toda tu astucia al escribir un programa, dejas muy poco margen para entenderlo cuando algo se rompe.

Parece una broma sobre programadores. En realidad, es una regla sobre complejidad.

La solución ingeniosa tiene un coste oculto

Cuando el código funciona, la astucia puede parecer eficiencia. Una expresión densa sustituye diez líneas normales. Una abstracción genérica resuelve seis casos de una vez. Un truco compacto elimina un bucle, una asignación o una función.

Luego pasan tres meses.

La persona que lee el código ya no tiene todo el problema en la memoria. Las hipótesis originales se han desvanecido. Aparece un fallo en producción en un caso que nadie imaginó. Y quien debe leer el código bajo presión quizá ni siquiera sea quien lo escribió.

Es entonces cuando llega el coste real de la astucia.

La pregunta importante deja de ser “¿Cuántas líneas me he ahorrado?” y pasa a ser “¿Cuántas ideas tengo que mantener a la vez en la cabeza para entender qué puede hacer este código?”.

Los primeros trabajos de Kernighan sobre estilo de programación iban exactamente en esa dirección. El objetivo no era hacer a los programadores menos sofisticados. Era hacer los programas más fáciles de razonar para otros humanos.

El código legible no es código para principiantes

A veces “manténlo simple” se interpreta como “evita técnicas avanzadas”. No es eso.

Un sistema sofisticado puede requerir ideas sofisticadas. La disciplina consiste en impedir que esa sofisticación se filtre por todas partes.

Si una parte del sistema necesita de verdad un algoritmo difícil, aíslalo. Ponle un nombre que explique su propósito. Deja las hipótesis junto a él. Prueba los bordes. Y mantén el resto del programa tan aburrido como sea posible.

El buen código no demuestra cuánto sabe su autor. Reduce cuánto necesita saber al mismo tiempo el siguiente lector.

Por eso la claridad escala mejor que la astucia. Una persona brillante puede entender un truco. Un equipo, un futuro mantenedor, alguien respondiendo a una incidencia y tu propio yo cansado a las dos de la mañana necesitan algo más duradero.

La mayor parte del debugging empieza antes del bug

En sus escritos posteriores sobre depuración, Kernighan y Rob Pike subrayan que la mayoría de los errores son bastante ordinarios y que una buena depuración empieza examinando evidencias y razonando hacia atrás desde lo que el programa hizo realmente.

Eso es mucho más fácil cuando el código tiene límites claros.

Funciones pequeñas reducen el área de búsqueda. Un estado explícito hace visibles las transiciones incorrectas. Los buenos nombres conservan la intención. Los tests convierten hipótesis en ejemplos ejecutables. Un logging adecuado puede transformar horas de adivinanzas en minutos.

Ninguna de estas técnicas parece espectacular.

Precisamente por eso funcionan.

La era de la IA hace esta regla más importante, no menos

La IA ya puede generar código con aspecto funcional más rápido de lo que la mayoría de los equipos puede revisarlo. Eso cambia el cuello de botella.

Escribir código se está abaratando. Entender código no.

Una función generada puede compilar. Puede pasar el caso feliz. Incluso puede parecer elegante. Pero el problema de mantenimiento sigue siendo humano: ¿qué supuso? ¿qué pasa cuando falla? ¿hace falta esta abstracción? ¿qué comportamiento fue intencional y cuál es solo un accidente de la implementación generada?

Si una herramienta puede producir 500 líneas en segundos, es tentador medir el progreso por cantidad de output. Pero el software no vale porque existan muchas líneas. Vale porque el sistema sigue siendo comprensible y se puede cambiar con seguridad.

Cuanto más rápido se produce código, más cara se vuelve la falta de legibilidad.

Cuatro preguntas para cada pull request

¿Puedo explicar esta sección sin ejecutar mentalmente cada línea? Si no, la abstracción quizá esté ocultando demasiado o demasiado poco.

Cuando falle, ¿dónde miraré primero? Si la respuesta es “en todas partes”, los límites son débiles.

¿La versión normal podría ser un poco más larga pero mucho más fácil de verificar? A veces unas líneas extra son más baratas que capas extra de pensamiento.

¿La siguiente persona entenderá por qué esto existe? El código conserva comportamiento. Los nombres, la estructura y los comentarios conservan intención.

Siempre habrá momentos en que una solución ingeniosa sea realmente la correcta.

Pero la astucia debería ser algo que el sistema gasta deliberadamente, no algo que el programador exhibe por defecto.

La advertencia de Kernighan ha sobrevivido porque el hardware cambió, los lenguajes cambiaron y ahora la IA está cambiando cómo se produce código; pero la persona que depura al final de la cadena sigue teniendo un cerebro finito.

¿Cuánto del código del que hoy te sientes más orgulloso seguirá pareciendo obvio para quien tenga que repararlo dentro de un año?