AOWS

Just another adrian’s weblog

Programar para humanos

leave a comment »

Todos nos hemos enfrentado a códigos interminables, sin un solo comentario, con una funcionalidad mal definida, con operaciones poco más que inexplicables… a veces incluso nos cuesta comprender lo que nosotros mismos hemos programado hace poco tiempo.

Por eso un buen código no es aquel que entienden las máquinas, sino el que entienden los humanos (y que obviamente funcione igual).

Aquí entran en juego muchos factores, pero el que quería comentar en esta entrada es la legibilidad, si un código es fácilmente entendible o no. Para explicar bien el concepto, nada mejor que entrar en materia:

[java]
if (valor != null && 0 <= valor && valor <= 50)
metodo();
[/java]

[java]
if (enRango(valor))
metodo();

private boolean enRango(Integer valor) {
return (valor != null && 0 <= valor && valor <=50);
}
[/java]

Quizá este ejemplo no sea lo suficientemente ilustrativo, pero sirve para al menos intuir por dónde voy. Ambos trozos tienen la misma funcionalidad, hacen lo mismo, pero el segundo código presenta una serie de ventajas; entre ellas, la de estar pensado para humanos.

Cuando en un futuro otra persona (o incluso nosotros mismos) revise este código, sólo por el nombre del método sabrá qué condición se está evaluando. Si además documentamos el método, entonces quedará niquelao.

Estos días estoy intentando aprender Ruby, un lenguaje dinámico al estilo PHP o Perl; de hecho las semejanzas con éste último son muy grandes. Entre otras cosas, comparten algo muy peligroso llamado shortcuts o atajos.

Peligroso en el sentido que hemos comentado, pues un código puede perder su legibilidad y complicar su mantenimiento. Por ejemplo, en Ruby los métodos devuelven el valor de la última expresión evaluada. Es decir, los siguientes trozos de código son equivalentes:

[ruby]
def prueba(texto)
# operaciones varias…
# …
return “texto pasado: #{texto}”
end
[/ruby]

[ruby]
def prueba(texto)
# operaciones varias…
# …
“texto pasado: #{texto}”
end
[/ruby]

El hecho de que el lenguaje permita que nos ahorremos una palabra puede hacer que el código sea más difícil de entender, al menos a primera vista.

Es un concepto muy importante que en estos ejemplos puede no haber quedado reflejado del todo, pero en sistemas complejos se nota, y mucho. A la máquina le es indiferente un código con más o menos líneas, y la penalización de rendimiento es totalmente despreciable (si no lo fuese, entonces la legibilidad dejaría de ser prioritaria).

A la hora de picar código se debería tener en cuenta que será revisado, tarde o temprano. ¿Cómo nos gustaría encontrarlo? Una buena práctica es la de revisar lo hecho el día anterior; si no se comprende a la primera, entonces es que algo falla.

Written by adrian

31 mayo, 2008 a 00:57

Publicado en Posts

Tagged with ,

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: