Etiquetas

, , , ,

Hace unos días fui a poner en la estantería el libro Beatiful Code y se abrió en un capítulo llamado Treating Code As an Essay, de Yukihiro Matsumoto. Enseguida me llamó la atención el título, no sé cómo se me pudo haber pasado ese capítulo.

Mis alumnos de informática pueden atestiguar que no aprueban las prácticas sin el código bien sangrado y «legible» (también hablé de ese tema varias veces en mi blog, últimamente en Belleza, fealdad y complejidad o Colega, let’s see the code). Les doy el coñazo que no inventamos lenguajes para facilitar el trabajo de las máquinas, sino el de los humanos, los programadores.

Por otro lado en la asignatura –de libre configuración– Seducciones de la Informática les pido como trabajo final un ensayo, en la definición e idea original de Montaigne.

Volviendo al tema del capítuo. Cuando lo ví no tenía tiempo, estaba saliendo de viaje, pero hoy me acordé y  lo leí. El primer párrafo dice:

Los programas comparten algunos atributos con los ensayos. La cuestión más importante para los ensayos es «¿de qué se trata?». Para los programas la fundamental es «¿qué hace?». De hecho el propósito  debe ser lo suficientemente claro para evitar que siquiera nos formulemos esas preguntas. No obstante, para los ensayos y programas, es siempre importante prestar atención a cómo está escrito cada uno. Aún si la idea es buena, será difícil transmitirla a la audiencia deseada si es difícil de entender. El estilo en el que están escritos es tan importante como su propósito. Ambos, ensayos y líneas de código, existen –antes que nada– para ser leídos e interpretados por seres humanos.

Yikihiro luego explica los aspectos que considera más relevantes para los programas. Aunque los explica para justificar el diseño de Ruby, pueden servir como regla general (especialmente, para mi gusto,  la primera y tercera):

  1. Brevedad: La brevedad es una virtud, definitivamente hay un coste de lectura para el ojo humano, el código debe eliminar la información redundante [*]
  2. Familiaridad: Las personas son más conservadoras de lo que pensamos. Las curvas de apredizaje elevadas crean estrés y reducen productividad. Un lenguaje no debe oblighar a los progamadores a trabajar con conceptos nuevos y complejos. No ser demasiado innovador es también una ayuda para el «código bello».
  3. Simplicidad: Si un programa es complicado de entender no puede tener belleza.
  4. Flexibilidad: Lo define como la «libertad de los hábitos forzados por las herramientas». Cuando un programador es forzado a hacer algo en contra de suis inenciones se genera más estrés, lo que afecta negativamente al programador.
  5. Balance: Ninguno de los elementos anteriores hará que el código sea bello, sino un adecuado balance entre ellos.

[*] Como contraste de brevedad muestra el siguiente código para el «Hola mundo»:

Java:

class Sample {}

public static void main(String[] argv) {
    System.out.println("Hola mundo")
}

Y luego la siguiente línea que hace exactamente lo mismo funciona igual en Ruby, Perl, PHP y Python (en Python es aún más breve, no hace falta el \n):

print "Hola mundo\n"

Unas pocas páginas más adelante del capítulo mencionado hay otro, Code in Motion, hacen referencia a otro ensayo Seven Pillars of Pretty Code, que da unos parámetros relacionados:

  • Fusión: El estilo del código nuevo debe ser similar al ya existente. No debe notarse la diferencia entre ambos.
  • Estilo libro: Hay que mantener las columnas limitadas ya que exigen un esfuerzo de desplazamiento de los ojos. La primera parte debe mantener la estructura fundamental, la derecha los detalles.  Si una línea es muy larga se puede hacer nombres más cortos, agrupar por similaridad  (pro ejemplo separando argumentos por líneas).
  • Separar bloques: Separar los bloques lógicos en cada función, así se facilita la lectura más rápida y en «diagonal».
  • …