Al programar, hay momentos en los que apetece condensar el código en una sola línea de manera sorprendente o recurrir a una solución ingeniosa que a otros difícilmente se les ocurriría. Es porque un código breve e ingenioso parece una demostración de habilidad. Pero si unos meses después aparece un error en ese código, a menudo hasta quien lo escribió tiene que examinarlo un buen rato para entender qué quería decir. La regla empírica que describe con agudeza esta situación es la «ley de Kernighan» (Kernighan's Law).
En pocas palabras, la ley de Kernighan enuncia el siguiente principio. Encontrar y corregir errores es el doble de difícil que escribir el código por primera vez, así que, si lo escribes de la manera más ingeniosa de la que eres capaz, luego no podrás corregirlo por tu cuenta. Este consejo de anteponer la claridad al ingenio sigue citándose ampliamente entre quienes se dedican a programar.
En este artículo veremos, por orden, cómo surgió la ley de Kernighan, qué significa la frase, qué malentendidos la rodean y cómo aplicarla en la práctica.
Por qué el código claro perdura más que el ingenioso
Una frase nacida en los Laboratorios Bell
Brian Kernighan, el autor de esta frase, es un informático canadiense que trabajó en los Laboratorios Bell de Estados Unidos. Junto con Dennis Ritchie escribió un libro considerado un manual de referencia del lenguaje C y participó activamente en el desarrollo de Unix. La K, una de las tres letras del nombre del lenguaje de procesamiento de texto awk, procede de su apellido. Desde 2000 da clases en la Universidad de Princeton.
- Fuente (The Elements of Programming Style). La frase apareció en «Los elementos del estilo de programación», libro que publicó en 1974 junto con su colega P. J. Plauger.
- Edición revisada (Second Edition). En 1978 salió la edición número 2. La frase en cuestión figura en el capítulo 2, dedicado a las fórmulas y expresiones.
- Motivación del libro (Textbook Examples). Los dos autores fueron reescribiendo uno por uno los ejemplos de código mal escrito en FORTRAN y PL/I que aparecían en los manuales de la época, y de ahí extrajeron reglas para escribir buen código.
El título del libro se inspira en «Los elementos del estilo» (The Elements of Style), un conocido manual de escritura. Todo el libro parte de la idea de que el buen código, como una buena frase, debe expresar su sentido con claridad y sin elementos superfluos.
Qué significa que sea el doble de difícil
El original consta de dos frases cuyo sentido es el siguiente. «Como todo el mundo sabe, depurar es el doble de difícil que escribir el programa por primera vez. Así que, si lo escribiste con todo el ingenio del que eras capaz, ¿cómo se supone que vas a depurarlo?». Aquí, la depuración (Debugging) consiste en encontrar y corregir los errores de un programa, conocidos como bugs.
(1) Corregir es más difícil que escribir
Al escribir código, tienes muy presente lo que quieres que haga. Cuando buscas un error, debes seguir el rastro en sentido inverso para averiguar en qué punto el comportamiento real se apartó de tu intención. Esto resulta más difícil porque el fallo se esconde en alguna parte que dabas por correcta.
(2) Si agotas tu ingenio, te quedas sin margen
Si escribes código al límite de tu capacidad, esa capacidad resultará insuficiente cuando toque depurarlo, una tarea el doble de difícil. Aquí, «el doble» es una forma de recalcar que la diferencia es grande y carece de la precisión de una medición.
(3) Por eso conviene escribir con claridad
La conclusión es que conviene reservar parte de tu ingenio. Si desde el principio escribes código que puedas entender usando más o menos la mitad de tu capacidad, cuando surja un problema tendrás margen suficiente para dar con la causa. De hecho, en el mismo libro también figura la regla «Escribe con claridad y evita pasarte de ingenioso» (Write clearly - don't be too clever).
Malentendidos en torno a la ley
La brevedad y el ingenio de la ley de Kernighan hacen que a veces se interprete en un sentido distinto del original.
¿Quiere decir que hay que evitar las técnicas difíciles?
La ley permite recurrir a técnicas difíciles cuando hacen falta. Usar un método sofisticado donde es realmente necesario es distinto de complicar a propósito un problema que admite una solución sencilla. Lo que conviene evitar es la costumbre de escribir código difícil de entender para presumir. El golf de código (Code Golf), un juego que consiste en usar el menor número posible de caracteres, es un ejercicio mental divertido. Si ese código se incorpora tal cual a un servicio real, quien tenga que corregirlo lo pasará mal.
La palanca de Kernighan, otra interpretación
El programador sueco Linus Åkesson reinterpretó la frase como la «palanca de Kernighan» (Kernighan's Lever). Según esta lectura, esforzarte por corregir código que supera tu nivel te ayuda a mejorar tus habilidades. Esta interpretación se aplica en contextos de aprendizaje. Para el código que varias personas usarán durante mucho tiempo, el consejo original es más seguro.
Cómo aplicar la ley de Kernighan en la práctica
La ley de Kernighan se traduce en varios hábitos que facilitan la lectura del código.
(1) Piensa primero en quien va a leer el código
El código se escribe una vez y se lee muchas. Usa nombres claros y evita concentrar demasiadas tareas en una sola línea para que puedas entender el código de inmediato al releerlo meses después y para que un colega que lo vea por primera vez también pueda hacerlo.
(2) Primero haz que funcione correctamente y luego haz que sea rápido
El mismo libro aconseja «Haz que funcione correctamente antes de hacerlo rápido». Puedes dejar para después los cambios que compliquen el código para mejorar el rendimiento, una vez que hayas comprobado dónde está la lentitud.
(3) Elige código fácil de corregir antes que código breve
Hoy en día, las herramientas de inteligencia artificial generan código complejo en un instante, pero la responsabilidad de entenderlo y corregirlo sigue recayendo en las personas. Si hay código que no puedes explicar, lo más seguro es evitar aceptarlo tal cual.
En un texto de 1979, Kernighan también señaló que las herramientas de depuración más eficaces siguen siendo la reflexión cuidadosa y las instrucciones de salida colocadas en los lugares adecuados. La idea es que, por encima de las herramientas sofisticadas, la base para resolver problemas es un código sencillo que se pueda examinar con calma.
La ley de Kernighan te orienta sobre dónde aplicar tu habilidad sin pedirte que la ocultes. A la larga, diez líneas corrientes que mañana se lean con facilidad te ahorrarán más tiempo que una línea ingeniosa escrita hoy.
El primer paso para escribir código que perdure es usar solo el ingenio suficiente para poder descifrarlo de nuevo por tu cuenta.
