Belleza de código

La primera vez que leí acerca de “belleza” en programación fue en un escrito de Paul Graham. La segunda vez fue a Tabo haciendo referencia al evangelismo de belleza de David Heinemeier Hansson sobre Ruby y programación en general en el video de Snakes and Rubies.
Tengo otra idea muy familiar que, personalmente, conozco bajo el nombre de “elegancia.” Código que es “elegante” y soluciones “elegantes” a problemas complejos. En mi cerebro he catalogado “elegancia” y “belleza” como dos ideas no intercambiables. Ojo que esta es mi categorización personal, nada canónico:

“Belleza” de código es la diferencia motivacional que existe entre:

inicio = Time.now.beginning_of_day

y

$inicio = mktime (0, 0, 0, date (“m”), date (“d”), date (“Y”));

El primer código, en Ruby, es a todas luces guapísimo. :)

“Elegancia” es, en mi diccionario, algo que no tiene que ver mucho con cómo se ve el lenguaje, sino pasos ingeniosamente elaborados para la resolución de un problema de la mejor forma posible. El código no será necesariamente bello, pero la solución puede ser elegante.

PHP es, definitivamente, no bello — por decirlo de una manera agradable. Sin embargo, eso no le quita que podamos escribir código elegante en él.

Vamos con un ejemplo real.

Estoy actualmente trabajando en un proyecto sujeto a bastantes cambios estructurales. Escribí una función de búsqueda para cada uno de los tipos de registros que manejamos en base a ciertos criterios. Estas funciones devuelven un array con los resultados. Por ejemplo:

function actividades_buscar ($db, $vista, $localidad, $linea, $mes, $anyo, $pagina)

Esta función se llamaba desde un solo lugar inicialmente, luego conforme vinieron los cambios empecé a usarla en algo de cuatro lugares distintos del sistema. En el lugar original no había mucho problema en entender el código, ya que le alimentaba con variables recibidas por GET.
Sin embargo, en los otros lugares donde hacía búsquedas predefinidas (hardcoded) como que ya no era tan legible:

$resultados = actividades_buscar ($db, “general”, “0000000000”, -1, -1, -1, $pagina);

(Ough!)

Pero lo peor fue cuando el cliente decidió añadir más criterios de búsqueda… así que añadí un par de parámetros más a mi función y actualizar en todos los lados, pero oops! se me escapó en una parte y el cliente detectó el bug. Ok, a corregir.

Luego el cliente decidió añadir otro criterio más de búsqueda y ya me estaba doliendo (podría decir físicamente) cambiar en N-lados lo mismo y tener un código que era horrible. La gota que derramó el vaso fue cuando el cliente pidió que también se pudiesen ordenar los resultados por columnas y tenía que pasar un parámetro de ordenamiento a mi función de búsqueda quedandome con una definición de:

function actividades_buscar ($db, $vista, $localidad, $linea, $acciones, $mes, $anyo, $criteria, $mes_inicio, $anyo_inicio, $mes_fin, $anyo_fin,$sort, $pagina)

(Oh, la humanidad.)

Obviamente no iba a entender ni papa de qué cosa es qué aquí:

function actividades_buscar ($db, “regional”, “0000000000”, -1, -1, -1, -1, ”, -1, -1, -1, -1, ”, $pagina)

Este código era tan horrible que me dije “Es un asco. No puedo creer que esto exista.” No tenía tiempo para corregir eso, pero era tan horrible y tenía tanto miedo que me pidiesen otro cambio en esa parte que decidí dejar de lado todo y sentarme a reescribir todo eso.

La solución final fue pasar cada uno de los criterios de búsqueda en un array, y si no mencionamos un criterio, éste obtiene un valor por defecto sensible. Eso significó reducir la declaración de mi función a:

function actividades_buscar ($db, $params)

y llamar la función con solamente los parámetros necesarios de la siguiente manera mucho más legible y elegante:

$resultados = actividades_buscar ($db, array (
        ‘vista’ => ‘general’,
        ‘pagina’ => $pagina_actual,
   )
);

Ahora sí tengo paz. :)

• Tags: php, programación, ruby