7 consejos para crear nombres significativos al programar

Los nombres están en todas partes del software. Se nombran las variables, las funciones, los argumentos, las clases y paquetes. Se nombran los directorios, los ficheros, las tablas de bases de datos.

Gran parte del tiempo que pasamos programando, lo pasamos dando nombre a las cosas. Si nuestro objetivo es mantener un código limpio, debemos pasar más tiempo del que creemos pensando en los nombres que ponemos y crear nombres significativos.

A continuación, mostraré unas simples reglas a la hora de crear buenos nombres.

Utiliza nombres que revelen una intención

Elegir un buen nombre puede llevar mucho tiempo, pero también puede ahorrarte más tiempo aún. Es por eso que debemos ser cuidadosos a la hora de elegir un nombre, e incluso de cambiar dichos nombres por unos mejores. Esto hará que los lectores (incluidos nosotros) entiendan mucho mejor el código con el que están trabajando.

El nombre de una variable, función, o clase, debe responder a las tres grandes preguntas:

• Por qué existe
• Qué hace
• Cómo se usa

Si un nombre necesita un comentario para que se entienda, entonces no revela su intención.

int t; // tiempo en días

La variable t no explica nada. No da a entender que muestra el tiempo que ha pasado, y mucho menos en días. Deberíamos elegir un nombre que especifique qué se está midiendo y la unidad de esa magnitud.

int timeInDays;
int timeSinceCreation;
int timeLastModification;

Elegir nombres que revelen una intención facilita la comprensión del código y por lo tanto es más fácil de entender y mantener.

Evita desinformar

A veces los programadores tendemos a crear nombres que no especifican correctamente el caracter de lo nombrado.

Dar pistas falsas

Por poner un ejemplo claro, si tenemos un grupo de teléfonos, y lo llamamos listaTelefonos, a no ser que la variable sea una List, no deberíamos llamarlo de esta manera. La palabra List tiene un significado claro para los programadores, y puede dar a entender que la variable sea del tipo List cuando lo que hemos creado es un array. En este caso, simplemente con «telefonos» sería más fácil de entender.

Nombres parecidos con variaciones mínimas

Imaginad encontraros una variable como «calculoDelTiempoEnSegundosDesdeModificacion» y un poco más abajo encontrar «calculoDelTiempoEnDiasDesdeModificacion».

El tiempo que utilizamos para diferenciar que la variable no es la misma que la de arriba es muy significativo. La comprensión es nula y distrae al lector.

Evita usar la letra l (ele)

La letra ele normalmente es muy dificil de diferenciar con el número 1. Se podría decir que lo ideal sería elegir una tipografía que distinga perfectamente estos dos caracteres, pero eso no es lo correcto. No todos usamos la misma tipografía y a veces el código puede ser público y descargable.

Usa nombres pronunciables

Aunque parezca mentira, a veces tendemos a escribir nombres que son imposibles de pronunciar. Normalmente esto se da cuando los programadores escribimos diminutivos de las palabras que queremos plasmar e incluso, cuando creamos nombres basados en siglas.

Un ejemplo claro sería una variable que genere un momento del tiempo genymdhms (generation date, year, month, day, hour, minute, and second). Parece algo ridículo, pero estos casos pasan más de lo esperado.

En este caso, una vez conoces esa variable, tal vez ya sepas para qué sirve. El problema viene cuando un nuevo compañero intenta leer el código y se encuentra con este nombre.

Comparemos:

class DateRecord {
    private Date genymdhms;
    private Date modymdgms;
.....

Con:

class DateRecord {
    private Date generationTimestamp;
    private Date modificationTimestamp;
.....

Usa nombres fáciles de buscar

Los nombres de una sola letra y las constantes numéricas solo crean dificultades a la hora de intentar buscarlas dentro del código.

Una búsqueda a MAX_NUMBER_OF_WEEK_DAYS puede ser mucho más sencilla de reallizar que buscar el número 5 en todo el código. El uso de la constante nos facilita la búsqueda y el entendimiento del código, por otro lado, es posible que el número 5 se encuentre en otros puntos del código que no tengan nada que ver con la constante que deseamos buscar.

De la misma manera, una única letra como la e es una de las elecciones más pobres a la hora de nombrar una variable. A parte de ser poco informativa, si la intentamos buscar en nuestro IDE es posible que nos muestre miles de resultados.

Nombra las clases con sustantivos

Las clases y objetos deberían ser sustantivos, como Customer, Account, AddressParser. Se deberían evitar palabras como Manager, Processor, Data, o Info en los nombres de las clases.

El nombre de una clase nunca debería ser un verbo.

Nombra los métodos con verbos

Los métodos deben representar una acción. Para hacerlo lo mejor es que se representen con verbos como borrarPagina o guardarPagina. Los “accessors” y “mutators” deben ser nombrados en base a los estandares de javabean con las palabras clave get y set.

No hagas “el gamba”

A veces, y sobretodo en equipos pequeños, es posible que haya un código de entendimiento entre los integrantes del grupo que fuerce la existencia de palabras o expresiones que todos entiendan. Aún así, es mejor evitar ser gracioso a la hora de dar un nombre. Imaginad el método “bombaNuclear”, a no ser que todos sepamos lo que significa, tal vez un nuevo lector no entienda que ese método se use para borrar los elementos de un objeto. Mejor llamarlo “deleteElements” y dejar el humor para el “afterwork”.

Amplia tu conocimiento

Los pasos descritos anteriormente para nombrar nuestro software son algunos de los ejemplos que nos ofrece Uncle Bob en su libro Clean Code, el cual recomiendo encarecidamente tanto si estás empezando a programar como si llevas una eternidad picando código. Este blog se nutre del conocimiento sacado de este libro y muchos otros y por ello recomiendo ampliar los horizontes y leer libros que nos ayuden a mejorar.

De todos modos, en este blog hablaremos de más puntos tratados en ese y otro libro como por ejemplo se hizo para el artículo de la creación adecuada de pruebas unitarias.