Artículo

Cuando no encuentras el nombre, el problema no es el nombre

Pasarse un rato buscando cómo llamar a una función suele significar que la función no está bien pensada. Algunas ideas para usar esa señal a tu favor.

1 de septiembre de 20262 min de lecturaEquipo ProTecno

Seguro que te ha pasado: tienes el cursor sobre el nombre de una función, llevas un minuto dándole vueltas y ninguna opción te convence. Mi experiencia es que en esos casos el problema casi nunca es de vocabulario. Lo que pasa es que la función hace dos cosas, o que no tienes del todo claro qué representa. El nombre solo es el síntoma.

Qué te está diciendo esa duda

function processData(data) {
  // valida, normaliza, guarda y notifica
}

processData no dice nada, pero no porque sea un mal nombre. Es que no hay ningún nombre bueno posible para algo que hace cuatro cosas. Si fueras honesto la llamarías validateNormalizeSaveAndNotify, y al escribir eso ya ves dónde está el problema.

El nombre puede ser tan corto como pequeño sea su alcance

Con esto la gente se pone muy tajante y no hace falta. Una variable de una letra está perfectamente bien en un cuerpo de tres líneas, donde se ve de un vistazo qué es. Esa misma letra en un módulo de trescientas líneas es una tortura para quien venga detrás.

// Bien: se ve entero de un vistazo
const total = items.reduce((n, item) => n + item.price, 0);

// Mal: se exporta, se usa en veinte sitios y nadie sabe qué es
export const d = new Map();

Nombra lo que es, no de qué tipo es

// El tipo ya se ve en la firma o en el editor, no aporta nada
const userArray = [];
const configObject = {};

// El plural y el contexto ya lo dicen
const users = [];
const config = {};

Con TypeScript o con un editor decente esto es todavía más evidente. El sufijo con el tipo es ruido que hay que leer cada vez.

Booleanos que se lean como una frase

if (!user.isDisabled) { ... }        // hay que pensarlo dos veces
if (user.isActive) { ... }           // se lee de corrido

Y cuidado con meter la negación dentro del propio nombre. Un notReady acaba tarde o temprano en un !notReady, y ahí ya nadie sabe qué está pasando.

Mejor consistente que perfecto

Si en el proyecto todo el mundo usa fetchX, no aparezcas con getX y retrieveX para lo mismo aunque te parezcan más precisos. En cuanto hay tres sinónimos para una operación, quien lee tiene que ir a comprobar si hacen cosas distintas. Y normalmente no.