¿Por qué preferir enums en vez de booleanos?

Bueno, el internet está dividido en este respecto, y creo que también tiene que ver con el lenguaje utilizado para argumentar, aunque creo que la respuesta que estoy a punto de ofrecerte, es válida para el lenguaje de la web, que es JS.

Para responder esta pregunta y a la vez intentando resumir el amplio debate en internet, aquí están 3 razones de peso para preferir enums antes que booleanos en tu aplicación web:

1. Usa enums para representar estados de tu app

Una de las razones de mayor peso es el simple hecho de que cuando necesites "estados" en tu aplicación uses strings que lo representen semánticamente, es decir, una app que necesita de diferentes estados no puede ser binaria, "active" "inactive" puede tener muchos estados más, "idle", "fetching", "submitting" etc.

Además de que tener un enum para representar el estado de tu aplicación, te permite hacerla crecer, siendo capaz de agregar estados nuevos con el tiempo sin refactorizar.

Es mejor hacer esto:

const state = app.getStatus(); // 'in review'

que esto:

const state = app.isActive ? 'Active' : 'Inactive';

2. Los booleanos false, son muy poco descriptivos

No siempre es claro lo que false significa.

Por ejemplo, si pensamos en que tenemos un estado isApproved que estamos trabajando con un booleano, ¿qué significaría el falso? ¿"NO_YET_APPROVED", "REJECTED", "PENDING", "IN REVIEW"?, sería difícil entender cuál es la situación real con un estado que no nos dice nada más que false.

👀 ¡Ojo!, aquí también es importante recordar que los estados negados como "UNAPPROVED" no son una buena opción, es mejor un estado positivo como "DENIED". Esto ayuda con la semántica.

3. Los enum son todavía más semánticos cuando los usamos en una función

A veces necesitamos una banderita (flag) que dentro de una función nos diga si realizamos un paso extra o no, por ejemplo: teniendo la función formatNumber(number [, includeDecimals]) donde el segundo parámetro puede decidir si el número retornado incluye decimales o no, la invocación podría ser formatNumber(price, false) lo que sería muy poco semántico al leerla, sería mejor: formatNumber(price, INT) teniendo incluso más opciones que solo true o false ("TWO_DIGIT", "TEXT_ONLY", "USD", "MXN", etc.).

Adicional a esto, usar enums en parámetros los convierte en "type-safe" pues es muy fácil intercambiar "flags" por error, pues al esperar booleanos es fácil equivocarse getValidation(data, true, false).

Seguro ya tienes en mente más ejemplos con parámetros donde será mejor usar enums explícitos.

Todo el tiempo me veo en la necesidad de tomar esta decisión entre enums y booleanos, por eso quiero dejarte un par de preguntas que suelo hacerme para saber cuál usar:

1. ¿Qué significa false?, esta pregunta te ayudará a saber si te hace falta contexto para el estado o si false puede significar más de una cosa, esto es un buen indicio para saber que un booleano es insuficiente.
2. ¿Es posible que necesite más estados en el futuro que solo false?, si volverás a tu código para agregar un estado en el futuro, cáele bien a tu yo del futuro, colocando de una vez un enum aunque tenga solo dos estados.

Espero esto te haga convertir tus isLoading en un enum state: 'idle' | 'fetching' 🤓 y ser mejor programador a partir de hoy.

¡Y ya está!, espero que esto te haga decidir usar más enums en tu código, déjame saber si esto te ha sido útil en mi twitter, también te dejo un par de enlaces que te pueden interesar (inglés).

Abrazo. Bliss.

StackOverflow answer

Kent C. Dodds on enums