No lo llames 'util', llámalo 'helper

Cuando estamos programando, es muy fácil encontrar situaciones en las que necesitamos una pequeña función que vamos a utilizar en muchas partes. Esta función no encaja en nungún sitio y encaja en todos, así que no sabemos muy bien dónde dejarla.

Este tipo de situaciones suele terminar con un método estático en algún fichero con otras funciones similares, aunque no tengan mucho que ver entre ellas.

Me gustaría analizar este tipo de situaciones.

Cuestión de nomenclatura

A menudo, encontrar nombres adecuados cuando estamos programando es una tarea más compleja de lo que parece. Dar un buen nombre es difícil. Un buen ejemplo de esto es ver a los padres tratando de encontrar un buen nombre para sus hijos; da igual que otros padres ya lo hayan hecho, ya que cada nombre define a la persona. Y para complicarlo más, algunos nombres tienen significados subjetivos.

De la misma manera, cada función, cada método, cada variable, cada clase, necesita un nombre. Y estos nombres van a definir su esencia, su razón de existir, su motivo para cambiar, su todo.

¿Cuál es el motivo para cambiar una función que se llama “helper”? ¿Hay que cambiarla cada vez que se necesite ayuda?

Muchos programadores creen que no merece la pena dedicar tanto tiempo a encontrar un nombre a una variable. A menudo, utilizan excusas como que no van a dedicar 15 minutos para nombrar un iterador. Claro que no. La importancia de un nombre es directamente proporcionar a su tiempo de vida. Llamar a un iterador “i” o “j” es un estándar de facto, y si no se va a usar más que como contador, es más que suficiente. Sin embargo, encontrarte un “@return i@” en un método es algo horrible que no aporta ningún tipo de información.

De la misma manera no es lo mismo encontrar un nombre para un método privado que para uno público. Aun así, es importante que el nombre del método defina lo que hace éste, de la manera más eficiente posible.

Pura perrería

En otras ocasiones, nos vence el desánimo y queremos quitarnos la cuestión del nombrado lo antes posible. En estos casos, decidimos meter la función en un “helper” o “util” y quitarnos el problema.

Este tipo de actitudes están incurriendo en una deuda técnica menor. Como todas las deudas, una pequeña puede hacerse muy grande poco a poco.

Otras ocasiones no nos damos cuenta de lo importante que es el nombre para una variable, método o clase. O, como vamos apurados de tiempo, decidimos que no tenemos tiempo para mejorar el nombre de la variable.

Nombres prohibidos

La mejor manera de evitar este tipo de situaciones es prohibir ciertas palabras en los nombres de las funciones. La verdad es que se trata de un método personal y difícilmente automatizable, ya que los programadores buscar la “programación clever”, encontrando huecos en todas las defensas. De esta manera, si prohibimos manager, no tardarán en llamarlo mgr, Mgr o controller.

Sin embargo, hay ciertos nombres que deberían estar prohibidos por redundantes:

• Manager, Controller,… Un método siempre controla o maneja algo. No tiene sentido usarlo en un nombre.
• Util, Helper,… ¿Qué sentido tiene una función que no ayuda o no es útil?
• Tool,… Una función es una herramienta, así que no es necesario enfatizarlo más.

Hay otros nombres cuyo uso debería estar restringidos, como son:

• Factory: debería utilizarse sólo en métodos que fabrican objetos.
• Toolbox: sólo en clases que mantienen grupos de singletons.
• Controller: sólo en paquetes (no métodos o clases) que contienen el Controlador de un MVC.
• Wrapper: puede llevar a confusión si se usa en toda la herencia.

Y también hay nombres que advierten de problemas:

• And, Or: El método ya hace dos cosas. Seguramente se pueda dividir.

Muchos más

Hay muchos otros nombres que no deberían utilizarse cuando se crean funciones. Hoy estoy particularmente poco inspirado. Sin embargo, espero que esto genere en una discusión sobre nombres buenos y malos. ¡Para eso están los comentarios!