Hasta ahora tu código se ejecutaba en línea recta: de la primera línea a la última, sin desviarse nunca. Eso es suficiente para describir una tarea de Taller Nómada, pero no para razonar sobre ella. Marta no quiere que el programa le repita lo que ya sabe: quiere que le diga cuáles de sus tareas están en riesgo, si Iván puede marcar una tarea como hecha o si el formulario de alta tiene un dato inválido. Todo eso son decisiones, y una decisión en JavaScript se escribe con una sentencia condicional. En esta lección aprenderás a bifurcar el flujo con if, else y else if, a construir condiciones compuestas que se lean bien, a mantener el código plano en lugar de anidarlo hasta hacerlo ilegible, y a decidir cuándo un ternario mejora el código y cuándo lo empeora.

1. Del flujo recto a la bifurcación
2. La sentencia if
3. else: el camino alternativo
4. else if: cadenas de decisión
5. Condiciones compuestas con &&, || y !
6. Paréntesis: la diferencia entre correcto y legible
7. Condiciones sobre valores truthy y falsy
8. El problema del anidamiento
9. Cláusulas de guarda y salida temprana
10. El operador ternario y sus límites
11. Caso práctico: clasificar la urgencia de una tarea
12. Caso práctico: validar un cambio de estado (R6)
13. Tabla de decisión de las reglas de negocio
14. Errores Comunes y Consejos
15. Ejercicios
16. Conclusión

En Sintaxis y Conceptos Básicos viste que JavaScript ejecuta las sentencias de arriba abajo, una detrás de otra. Una estructura de control rompe esa linealidad: permite que ciertas sentencias se ejecuten solo en determinadas circunstancias, o que se ejecuten muchas veces.

Las estructuras de control se dividen en dos familias:

Esta lección cubre la selección con if. El switch llega en Sentencias Switch y la iteración en Bucles: for, while, do-while.

La forma más simple: una condición y un bloque que se ejecuta solo si esa condición es verdadera.

Anatomía, pieza a pieza:

• if es la palabra reservada. No lleva paréntesis pegado obligatoriamente, pero se escribe siempre if (.
• (horasEstimadas > 40) es la condición. Los paréntesis son obligatorios. Dentro va cualquier expresión que produzca un valor; JavaScript lo convierte a booleano igual que hacía Boolean() en Conversión de Tipos y Comparaciones.
• { ... } es el bloque que se ejecuta si la condición es verdadera. Con let y const, todo lo declarado dentro solo existe dentro.
• No lleva ; después de la llave de cierre. Un if es una sentencia de bloque, no una expresión.

La salida del ejemplo:

Si cambias 46 por 12, el aviso no aparece y solo se imprime la segunda línea. El programa eligió no ejecutar un trozo de código.

JavaScript permite omitir las llaves cuando el cuerpo tiene una sola sentencia:

Funciona, pero es una fuente clásica de errores. Mira qué ocurre al añadir una segunda línea:

La indentación sugiere que ambas líneas pertenecen al if, pero la indentación no significa nada en JavaScript. Sin llaves, el if solo gobierna la primera sentencia; la segunda es código normal que se ejecuta siempre. El error es invisible al leer y evidente al ejecutar.

Norma del curso: llaves siempre, aunque el cuerpo tenga una sola línea. No cuesta nada y elimina una categoría entera de fallos.

else define qué hacer cuando la condición es falsa. No lleva condición propia: es "en cualquier otro caso".

Se ejecuta exactamente uno de los dos bloques, nunca los dos ni ninguno.

Cuando hay más de dos caminos, se encadenan condiciones con else if. Clasificar la prioridad de una tarea en un peso numérico es el ejemplo canónico del proyecto:

Tres detalles importantes:

1. Las condiciones se evalúan en orden y la cadena para en la primera verdadera. Si prioridad es 'alta', las otras dos comparaciones ni siquiera se ejecutan. El orden importa.
2. El else final es la red de seguridad. Captura los valores que no esperabas: un 'ALTA' en mayúsculas, un undefined, un error de escritura. Sin él, peso se quedaría en undefined y el fallo aparecería mucho más adelante, en otro sitio, disfrazado de NaN.
3. let peso; va antes del if. Si declararas const peso = 3; dentro del bloque, esa variable solo existiría dentro de ese bloque y desaparecería al salir. Declarar fuera y asignar dentro es el patrón habitual.

Técnicamente else if no es una construcción nueva: es un else cuyo cuerpo es otro if. Se escribe en la misma línea por convención, para que la cadena se lea como una lista de casos y no como una escalera.

En Operadores Básicos aprendiste los operadores lógicos y su cortocircuito. Dentro de un if es donde despliegan toda su utilidad.

La regla R10 del proyecto dice: una tarea vencida (fechaLimite pasada y estado distinto de 'hecha') se destaca. Son dos condiciones que deben cumplirse a la vez, así que se unen con &&:

Recuerda de El Proyecto del Curso por qué fechaLimite < HOY funciona sin conversiones: el formato ISO 'yyyy-mm-dd' ordena alfabéticamente igual que cronológicamente.

Con || expresamos "cualquiera de estas situaciones justifica revisar la tarea":

Y ! invierte una condición. Estas dos líneas son equivalentes:

La segunda es claramente mejor. Usa ! para negar variables booleanas, no para negar comparaciones: para eso existen !==, <= y >=.

&& tiene mayor precedencia que ||, igual que * la tiene sobre +. Eso significa que esta condición:

se agrupa así:

Puede que sea lo que querías, o puede que no. El problema es que quien lea el código no puede saberlo. Compara con la otra agrupación posible:

Con prioridad = 'alta' y horasEstimadas = 5, la primera versión da true y la segunda false. Son condiciones distintas que se parecen mucho.

Norma: en cuanto una condición mezcle && y ||, escribe los paréntesis aunque la precedencia ya haga lo correcto. No son para el motor: son para la persona que revise el código dentro de seis meses.

Cuando una condición crece demasiado, la mejor herramienta no son más paréntesis sino variables booleanas con nombre:

El if final ahora se lee como una frase en español: está abierta, y o bien está vencida o bien es importante. Cada variable intermedia documenta una idea del negocio y puedes imprimirla por separado cuando algo no cuadre. Esta técnica —dar nombre a los trozos de una condición— es la que más mejora la legibilidad del código real.

En Conversión de Tipos y Comparaciones viste los ocho valores falsy: false, 0, -0, 0n, '', null, undefined y NaN. Todo lo demás es truthy. Un if aplica exactamente esa conversión a su condición.

Esto permite escribir comprobaciones muy cortas:

Cómodo, pero peligroso, porque if (valor) mete en el mismo saco situaciones muy distintas. Observa qué pasa con los campos del proyecto:

Dos consecuencias directas sobre Nómada Tareas:

horasEstimadas puede ser un número válido y falsy. Si un día se admitieran tareas de 0 horas, if (horasEstimadas) las trataría como si el campo faltase. La comprobación honesta es explícita:

Un array vacío es truthy. if (etiquetas) da true aunque no haya ninguna etiqueta, porque el array existe. Como etiquetas es siempre un array (nunca null), lo que hay que mirar es su longitud:

Norma práctica: usa if (valor) solo cuando de verdad quieras decir "hay algo utilizable aquí" y ninguno de los valores falsy sea legítimo para ese campo. En todos los demás casos, escribe la comparación completa: === null, > 0, .length === 0, !== ''. El código gana en claridad lo que pierde en brevedad.

Un if puede contener otro if. La primera vez que se necesita, el resultado parece razonable:

Este código funciona, pero tiene tres problemas serios:

1. El caso importante está enterrado. Para saber cuándo se imprime "Vencida y asignada" hay que reconstruir mentalmente tres condiciones acumuladas.
2. Los else están lejos de su if. El else de la línea final pertenece al primer if, veinte líneas más arriba.
3. Cada nivel nuevo multiplica los caminos. Tres niveles ya dan ocho combinaciones posibles.

A esta forma se la llama código en flecha (arrow code), porque la indentación dibuja una punta de flecha hacia la derecha. Es una de las señales más fiables de que una lógica necesita reescribirse.

La alternativa es la cláusula de guarda: en lugar de anidar el caso bueno dentro de comprobaciones sucesivas, se descartan primero los casos excepcionales y se deja el camino principal al final, sin indentar.

Reescribimos el ejemplo anterior como una cadena plana de else if, ordenada del caso más excluyente al más general:

Mismo comportamiento, un solo nivel de indentación y cuatro casos que se leen como una lista. Cada línea responde a una pregunta y la cadena se detiene en la primera respuesta afirmativa, así que las condiciones posteriores pueden dar por supuesto todo lo anterior: cuando se evalúa fechaLimite < HOY, ya sabemos con certeza que la tarea no está hecha y que tiene responsable.

Un segundo patrón, muy útil en validaciones, es acumular el motivo del rechazo en una variable:

titulo.trim() elimina los espacios de los extremos, de modo que un título con solo espacios se detecta como vacío: exactamente lo que exige la regla R2.

Una nota sobre el nombre. "Salida temprana" describe salir inmediatamente de un bloque de lógica en cuanto se detecta un caso inválido. Su forma canónica usa return dentro de una función, y esa herramienta llega en Definición y Llamada de Funciones. Mientras tanto, la cadena plana de else if te da el mismo beneficio principal —cero anidamiento y casos ordenados— con lo que ya sabes. Cuando conozcas las funciones, este mismo código se convertirá en tres líneas con return y te resultará natural.

El ternario condicion ? valorSiVerdadero : valorSiFalso que viste en Operadores Básicos es una expresión: produce un valor. Esa es la clave para saber cuándo usarlo.

Úsalo para asignar o interpolar un valor, donde brilla:

Con un if/else harían falta cinco líneas y una variable let que después no vuelve a cambiar. El ternario permite mantener const, que es siempre preferible.

No lo uses para ejecutar acciones. Esto funciona pero es un abuso: el ternario está pensado para producir valores, no para elegir efectos secundarios.

No lo anides más de una vez. Un ternario dentro de otro todavía se lee si se formatea en columna, pero tres ya no:

Cuando la cadena de casos crece, la construcción adecuada es un if/else if o un switch, que verás en la lección 02-03.

Marta necesita una etiqueta de urgencia que combine dos señales: la prioridad y los días que faltan para la fecha límite. Este es el primer trozo de lógica de negocio real del proyecto.

Qué hay que entender aquí:

• new Date(fechaLimite) - new Date(HOY) aprovecha algo que ya conoces: cuando se usa el operador -, JavaScript convierte cada fecha a su número de milisegundos desde 1970. Restarlas da la distancia en milisegundos; dividir entre MS_POR_DIA la convierte en días. Es el único caso del proyecto donde usamos Date, tal como se anunció en la lección 01-08.
• El orden de la cadena es lógica de negocio, no capricho. Una tarea hecha nunca es urgente aunque haya vencido, así que estaCerrada va primero. Una vencida es crítica sin más comprobaciones, así que va segunda.
• Las cuatro variables booleanas hacen la cadena autoexplicativa. Sin ellas, la cuarta condición sería (diasRestantes >= 0 && diasRestantes <= 3) || prioridad === 'alta', correcta pero opaca.

La regla R6 dice que solo son válidas las transiciones del ciclo de vida. Recuerda el diagrama de la lección 01-08:

Traducido a condiciones: son válidas cuatro transiciones y ninguna más. Iván intenta pasar una tarea de 'pendiente' directamente a 'hecha', y el programa debe rechazarlo con un motivo comprensible.

Fíjate en la estructura: dos guardas al principio (estado inexistente, estado repetido), cuatro casos permitidos en medio y un else que rechaza todo lo demás. Rechazar por defecto es la política correcta en una validación: si mañana alguien añade un estado nuevo y olvida su transición, el sistema la rechazará en lugar de aceptarla en silencio.

Esta cadena de seis else if es larga, y hay una razón: cada rama compara dos variables. En la lección 02-03 verás que un switch no mejora este caso concreto, y en el Módulo 4 lo resolverás con un objeto de consulta en cuatro líneas. De momento, esta versión es explícita y correcta, que es lo que importa.

Antes de escribir un if complicado conviene dibujar una tabla de decisión: una fila por caso, una columna por condición y una columna con el resultado. Esta es la de las validaciones que Nómada Tareas aplica al aceptar una tarea nueva.

La tabla se traduce casi mecánicamente a una cadena de guardas: cada fila es un else if que asigna el mensaje de rechazo. Escribirla antes de programar tiene dos ventajas: descubres casos olvidados mientras la rellenas, y te da la lista de pruebas que ejecutarás en el Módulo 8.

Usar = en lugar de == o ===. El error clásico.

= asigna, no compara. La expresión vale 'hecha', que es truthy, así que la condición siempre se cumple y además has destruido el valor original. Con const obtendrás un TypeError que te salvará; con let, un fallo silencioso. Lee siempre === en voz alta como "es igual a" y = como "recibe".

Comparar con == por costumbre. '0' == false es true y null == 0 es false. Usa === siempre, tal como quedó establecido en la lección 01-07.

Poner ; después de la condición.

El ; es el cuerpo vacío del if, y el bloque siguiente es un bloque suelto que se ejecuta pase lo que pase. No hay error ni aviso.

Encadenar comparaciones como en matemáticas. if (0 < horas < 40) no hace lo que parece: evalúa 0 < horas, obtiene true o false, y lo compara con 40 convirtiéndolo a 1 o 0. Siempre da true. Lo correcto es horas > 0 && horas < 40.

Olvidar el else final. Si una cadena else if asigna una variable, sin else esa variable puede quedarse en undefined. Añade siempre un caso por defecto, aunque solo sea para registrar un error.

Repetir la variable en cada comparación. prioridad === 'alta' || 'media' no compara con 'media': evalúa prioridad === 'alta' y, si es falso, devuelve 'media', que es truthy. La condición se cumple siempre. Hay que escribir prioridad === 'alta' || prioridad === 'media'.

Consejo: convierte condiciones largas en booleanos con nombre. Es la técnica de esta lección que más impacto tiene en código real.

Consejo: ordena las cadenas del caso más específico al más general. Si el caso general va primero, los específicos nunca se alcanzan.

Ejercicio 1 — Etiqueta de carga de trabajo

Marta quiere saber de un vistazo si una tarea es asumible. Escribe una cadena if/else if que, a partir de horasEstimadas, asigne a una variable carga uno de estos valores, y que rechace con un mensaje de error los valores que incumplen la regla R3:

Pruébalo con 2, 12, 30 y -3.

Ejercicio 2 — Semáforo de la tarea

Con estas variables, calcula una variable semaforo con valor '🔴', '🟠' o '🟢' según estas reglas, usando variables booleanas con nombre para que el if final se lea como una frase:

• 🔴 si la tarea no está hecha y su fecha límite ya pasó.
• 🟠 si no está hecha, la fecha no ha pasado y la prioridad es 'alta'.
• 🟢 en el resto de casos.

Imprime después una línea con el semáforo y el título. Resuelve la parte final (elegir el texto que acompaña al semáforo: 'urgente', 'atención' o 'en plazo') con un ternario donde sea razonable.

Ejercicio 3 — Quién puede cambiar el estado

Amplía la validación de la sección 12 con una regla adicional de Taller Nómada: solo el responsable de la tarea o Marta (coordinadora) pueden cambiarle el estado. Añade las variables responsable y usuario, y haz que la validación rechace el cambio con un motivo claro cuando el usuario no tenga permiso. Ten cuidado con el orden: comprobar el permiso debe ir antes de comprobar la transición, porque no tiene sentido explicar que la transición es inválida a alguien que no podía tocarla.

Pruébalo con: responsable 'Iván' y usuario 'Lucía' (debe rechazar por permiso), y responsable 'Iván' y usuario 'Marta' con transición en-curso → hecha (debe permitir).

Ejercicio 1

La clave está en descartar primero los valores inválidos. Una vez superada esa guarda, sabemos que horasEstimadas está entre 0 (exclusive) y 40, así que las condiciones siguientes solo necesitan el límite superior: <= 4, <= 15 y el else. No hace falta escribir horasEstimadas >= 5 && horasEstimadas <= 15, porque llegar a esa rama ya garantiza que es mayor que 4. Esa acumulación implícita es la gran ventaja de las cadenas else if frente a if sueltos.

Con -3: entra en la primera rama, carga vale 'inválida' y se registra el error. Con 2: 'ligera'. Con 30: 'pesada'.

Ejercicio 2

Las tres variables booleanas convierten el if en una lectura directa: "si está abierta y ha vencido...". Sin ellas, la primera condición sería estado !== 'hecha' && fechaLimite < HOY, que exige releer dos veces.

El ternario doble para nota está en el límite de lo aceptable: son tres casos sobre una sola variable y se alinean visualmente. Si hubiera un cuarto semáforo, la respuesta correcta sería un if/else if o el switch de la próxima lección.

Ejercicio 3

Con usuario = 'Lucía' y responsable = 'Iván', la primera guarda corta inmediatamente: ✗ Lucía no puede modificar una tarea de Iván. Y observa que ni siquiera se evalúa si la transición era válida, que es justo lo que pedía el enunciado.

tienePermiso merece su propia variable porque expresa un concepto del negocio —autorización— distinto del concepto de transición válida. Cuando mañana el permiso se complique (por ejemplo, permitir también a un revisor asignado), solo cambia esa línea.

El ternario del console.log está bien empleado: elige un valor —el prefijo ✓ o ✗— dentro de una plantilla, que es exactamente su cometido.

Tu código ya toma decisiones. Sabes escribir un if con llaves siempre, añadir un else para el camino alternativo y encadenar else if para clasificar en más de dos casos, aprovechando que cada rama da por supuesto todo lo que descartaron las anteriores. Sabes combinar condiciones con &&, || y !, poner paréntesis por legibilidad aunque la precedencia ya sea correcta, y —lo más importante— dar nombre a los trozos de una condición para que el if final se lea como una frase del negocio.

También sabes evitar dos trampas frecuentes: confiar en truthy/falsy cuando 0, '' o un array vacío son valores legítimos, y anidar if dentro de if hasta dibujar una flecha en el margen. La cadena plana de guardas es tu herramienta contra el anidamiento, y el ternario tu herramienta para asignar uno de dos valores, nunca para ejecutar acciones ni para encadenar cuatro casos.

Aplicado al proyecto, ya has implementado dos piezas reales de Nómada Tareas: la clasificación de urgencia que combina prioridad y días restantes, y la validación de transiciones de estado de la regla R6, con permisos incluidos.

Pero fíjate en algo: toda esa lógica se aplica a una sola tarea. Marta tiene un backlog de seis, y el mes que viene tendrá cuarenta. Copiar el bloque de urgencia cuarenta veces no es una opción. Eso se resuelve en Bucles: for, while, do-while, donde aprenderás a repetir un bloque de código tantas veces como haga falta y a recorrer todas las tareas del taller para sumar sus horas, encontrar la más urgente y contar cuántas lleva cada persona. Con condicionales dentro de bucles tendrás, por fin, un programa que razona sobre datos de verdad.