Clean Code — Funciones

Esto forma parte de una serie de artículos sobre mi lectura del libro Clean Code, de Robert C. Martin.

Hemos hablado de la atención a los detalles que debemos tener cuando escribimos nuestro código, también sobre la importancia de los nombres que asignamos a las diferentes partes de nuestro código, ahora le toca el turno a las funciones.

Según el autor las funciones son unos de los elementos más antiguos en el mundo de la programación, aunque ahora están más reflejados como métodos de clases.

La frase más elocuente al hablar sobre las funciones resa:

“La primera regla de las funciones es que deben ser de tamaño reducido. La segunda es que deben ser todavía más reducidas.”

El autor indica que debemos seguir dos reglas básicas a la hora de escribir funciones, y todo se basa en hacer las funciones lo más reducidas posible. Para lograrlo tenemos que tomar en cuenta que:

“LAS FUNCIONES SÓLO DEBEN HACER UNA COSA. DEBEN HACERLO BIEN Y DEBE SER LO ÚNICO QUE HAGAN.”

Al parecer esta es la clave principal que gira en torno de las funciones, y para lograrlo tenemos que procurar escribirlas de tal manera que el contenido esté tan solo un nivel por debajo del nombre de la función. Es una tarea difícil llegar a este nivel de abstracción pero presenta grandes ventajas a la hora de leer el código que escribamos.

El autor entrega indicaciones más detalladas y con respecto a los bloques condicionales, dice:

“Los bloques en instrucciones if, else, while y similares deben tener una línea de longitud que, seguramente, sea la invocación de una función. De esta forma, no sólo se reduce el tamaño de la función, sino que también se añade valor documental ya que la función invocada desde el bloque puede tener un nombre descriptivo.”

Esto me hace pensar en cuántas veces he escrito bloques if, else; que dentro de si, tienen muchas sentencias que ejecutan más de una tarea.

Me ha llamado la atención la idea de escribir código que pueda ser leído de manera descendente, y para lograrlo debemos organizar las funciones de tal manera que las funciones se encuentren inmediatamente por debajo de la función que la llama.

A lo largo de todo el libro se da mucha relevancia a la importancia de los nombres, y en el caso de las funciones también es aplicable este cuidado. Los nombres de las funciones deben describir lo mejor posible lo que hace la función, siguiendo el principio de mínima sorpresa, el autor comenta:

“Recuerde el principio de Ward: «Sabemos que trabajamos con código limpio cuando cada rutina es más o menos lo que esperábamos»”

La idea es muy clara, aunque resulta un poco difícil al comienzo ponerla en práctica en nuestro trabajo diario, vale la pena ese esfuerzo ya que nos ayuda a manejar mucho mejor la complejidad de nuestro código.

Los argumentos son otro de esos elementos en los que el autor hace mucho hincapié en la simplicidad, a tal punto de decir:

“El número ideal de argumentos para una función es cero. Después uno (monádico) y dos (diádico). Siempre que sea posible, evite la presencia de tres argumentos (triádico). Más de tres argumentos (poliádico) requiere una justificación especial y no es muy habitual.”

La mejor forma de entender esto es que nuestros métodos de clases siempre deben interactuar con las propiedades de la clase cambiando el estado del objeto. En este sentido los métodos no reciben parámetros, pero en casos en los que deben recibir un parámetro para cumplir su cometido no debe ser mayor a 3.

Luego pasamos a escribir nombres de funciones perfectamente combinadas con sus argumentos, el autor nos muestra este ejemplo:

“writeField(name), que nos dice que name es un campo (field). Éste es un ejemplo de palabra clave como nombre de función.”

Esto son de esas cosas que me han dejado muy entusiasmado y hasta me han hecho aumentar mi amor por la programación, al ver un método de ese estilo writeField(name), está todo demasiado explícito aunque estemos fuera de contexto es sumamente claro que la función debe escribir un campo.

Uno de los temas que más me ha costado asimilar y poner en práctica, (debido a malos hábitos) es la idea de no tener efectos secundarios en las funciones. Esto resulta duro, cuando veo mi código escrito hasta ahora. El autor lo dice de forma tácita:

“Los efectos secundarios son mentiras. Su función promete hacer una cosa, pero también hace otras cosas ocultas.”

Y en retrospectiva, la cantidad de dolores de cabeza que esto me ha causado, y que habría podido evitar me parece increible. Tan solo por no tener presente esa idea en mi cabeza a la hora de escribir código.

En esta línea de pensamientos el autor indica que debemos siempre separar consultas de comando, esto quiere decir que nuestras funciones debe hacer algo como cambiar el estado de un objeto o deben responder algo. La idea es separar estas tareas, porque de no hacerlo estamos cometiendo el error de hacer que la función haga dos tareas cometiendo un de los errores comentados al principio del capítulo.

El tema de las funciones limpias ha sido muy interesante para mi, que me presenta muchos retos para trabajar. Se necesita tiempo para desarrollar buenos hábitos y desterrar los malos, no es algo que se logre de la noche a la mañana, es necesario dedicar tiempo y pensar mucho nuestro código, ser autocríticos. El autor nos dice:

“Cuando creo funciones, suelen ser extensas y complicadas, con abundancia de sangrados y bucles anidados… Al final, consigo funciones que cumplen las reglas detalladas en este capítulo. No las escribo al comenzar y dudo que nadie pueda hacerlo.”

No pensemos que vamos a escribir siempre nuestro código siguiendo los lineamientos antes explicados a la primera, la razón es que, nuestra principal preocupación es escribir código que funcione y eso en muchos casos ya resulta muy difícil para la mayoría de nosotros.

Pero la idea no es parar cuando nuestro código funciona, luego debemos dar el segundo paso y es limpiar nuestro código, ese es el paso que muchos olvidamos y pasa que, el código se degrada a tal punto que no queremos ni ver nuestro propio código. Pero resulta igual de importante hacer código que funciona que hacer código limpio.