Condicionales en programación: if, else y switch desde cero

Cuando el programa tiene que elegir

En las entregas anteriores de la serie de Fundamentos de programación, nuestros programas iban en línea recta: instrucción uno, instrucción dos, instrucción tres, fin. Pero un programa de verdad no va siempre por el mismo carril. Tiene que decidir.

“Si el usuario es mayor de edad, déjale pasar; si no, no.” “Si hay stock, vende; si no, avisa de que está agotado.” Esa capacidad de elegir un camino u otro según lo que pase es el control de flujo, y su herramienta estrella son los condicionales. Aquí es donde tu código empieza a parecer inteligente.

El if: hacer algo solo si se cumple una condición

El bloque más básico es el if (en español, “si”). Ejecuta un trozo de código solo si una condición es verdadera. Y la condición, como vimos en los operadores, es una pregunta que se resuelve en verdadero o falso.

edad = 20

SI edad >= 18 ENTONCES
  mostrar "Puedes pasar"
FIN SI

Si edad >= 18 es verdadero, se ejecuta el mensaje. Si fuera falso, el programa se salta ese bloque entero y sigue como si nada. Así de simple: una pregunta, y un trozo de código que solo corre cuando la respuesta es que sí.

El else: y si no se cumple

Casi siempre quieres hacer una cosa cuando se cumple y otra cuando no. Para eso está el else (“si no”):

SI edad >= 18 ENTONCES
  mostrar "Puedes pasar"
SI NO
  mostrar "Lo siento, eres menor"
FIN SI

Ahora hay dos caminos y el programa toma exactamente uno: o el del if, o el del else, nunca los dos. Es la bifurcación clásica que dibujábamos con un rombo en el diagrama de flujo de la primera entrega.

El else if: varios caminos en cadena

¿Y si hay más de dos opciones? Encadenas con else if (“si no, si…”). El programa va probando condiciones de arriba abajo y se queda con la primera que sea verdadera:

SI nota >= 9 ENTONCES
  mostrar "Sobresaliente"
SI NO SI nota >= 7 ENTONCES
  mostrar "Notable"
SI NO SI nota >= 5 ENTONCES
  mostrar "Aprobado"
SI NO
  mostrar "Suspenso"
FIN SI

Importante: en cuanto una condición se cumple, las de abajo ni se miran. Por eso el orden importa. Si pusieras nota >= 5 arriba del todo, un 9 también cumpliría “mayor que 5” y se quedaría en “Aprobado”, sin llegar nunca a “Sobresaliente”. Las condiciones van de la más exigente a la menos.

El switch: cuando comparas siempre la misma variable

Cuando tienes muchos caminos pero todos comparan la misma variable contra valores fijos, el else if encadenado se hace pesado. Ahí encaja mejor el switch:

SEGUN dia
  CASO "lunes":
    mostrar "Empieza la semana"
  CASO "viernes":
    mostrar "Por fin"
  CASO "sabado":
  CASO "domingo":
    mostrar "Fin de semana"
  POR DEFECTO:
    mostrar "Dia normal"
FIN SEGUN

El switch mira el valor de dia y salta directo al caso que coincide. El POR DEFECTO (default) es el “si no coincide ninguno”, como un else. Un detalle que confunde al principio: en muchos lenguajes, si no pones un break al final de cada caso, la ejecución se cuela al siguiente. Eso a veces se usa a propósito (como juntar sábado y domingo arriba), pero más de una vez es un bug. Ojo con eso.

El ternario: un condicional en una línea

Para decisiones muy simples, escribir cinco líneas de if/else es exagerado. Ahí entra el operador ternario que asomó en la entrega de operadores:

mensaje = edad >= 18 ? "Adulto" : "Menor"

Se lee: “¿edad mayor o igual que 18? Si sí, ‘Adulto’; si no, ‘Menor’”. Es un if/else comprimido en una línea, perfecto para asignar un valor u otro según una condición. Consejo: úsalo solo para casos cortos. Si la lógica es enrevesada, un ternario se vuelve ilegible y es mejor un if de toda la vida.

Condiciones compuestas

Una condición no tiene por qué ser una sola pregunta. Con los operadores lógicos && (Y), || (O) y ! (NO) puedes combinar varias:

SI edad >= 18 Y tieneEntrada ENTONCES
  mostrar "Adelante"
FIN SI

Ahí entran las dos cosas a la vez: tiene que ser mayor de edad y tener entrada. Con || bastaría con una. Combinar condiciones es lo que te permite expresar reglas del mundo real, que casi nunca dependen de un solo factor.

El peligro de anidar demasiado

Puedes meter un if dentro de otro if dentro de otro. Se llama anidar, y un poco está bien. El problema es pasarse:

SI usuario existe ENTONCES
  SI usuario activo ENTONCES
    SI usuario tiene saldo ENTONCES
      SI producto en stock ENTONCES
        comprar
      FIN SI
    FIN SI
  FIN SI
FIN SI

Esto tiene nombre, y es de los mejores que ha dado la profesión: código Hadouken, o como lo gritamos los que crecimos con el Street Fighter, un «ayuuuken», porque las sangrías escalonadas dibujan clavadita la onda vital de Ryu saliendo en diagonal. La primera vez que lo ves tiene gracia. La segunda, cuando te toca mantenerlo, ya no tanta: es difícil de leer, fácil de romper y un imán de errores. Cada nivel que añades, más se aleja el código del margen y más te pierdes.

Guard clauses: el truco que lo arregla

La solución se llama guard clause (cláusula de guarda), y es de esos trucos que te cambian la forma de programar. En vez de anidar para llegar al caso bueno, sales pronto de los casos malos:

SI usuario no existe ENTONCES salir
SI usuario no activo ENTONCES salir
SI usuario sin saldo ENTONCES salir
SI producto sin stock ENTONCES salir

comprar

Mismo comportamiento, pero plano y legible. Primero descartas todo lo que impide continuar, cada cosa en su línea, y al final, sin sangrías, queda la acción que importa. Lee de arriba abajo como una lista de requisitos. Cuando empieces a escribir guard clauses en lugar de pirámides, sabrás que estás pillándole el truco a esto.

El bug que se cuela: asignar en vez de comparar

Hay un fallo de condicionales tan clásico que merece su propio aviso, y enlaza con lo que vimos en los operadores. Dentro de un if, pretendías comparar con ==, pero escribiste un solo = y, sin darte cuenta, asignaste:

SI usuario = "admin" ENTONCES    // ¡mal! esto ASIGNA, no compara
  dar acceso total
FIN SI

En muchos lenguajes eso no da error: mete “admin” en la variable y, encima, la condición se evalúa como verdadera siempre. Resultado: das acceso total a todo el mundo y te vuelves loco buscando por qué. Comparar es == (o mejor ===); asignar es =. Cuando un if se cumple “siempre” o “nunca” sin sentido, sospecha de esto lo primero.

Y un detalle relacionado: muchos lenguajes consideran ciertos valores como verdaderos o falsos sin necesidad de comparar. Un 0, una cadena vacía o un null suelen valer como “falso”; casi todo lo demás, como “verdadero”. Es cómodo (SI lista ENTONCES para “si la lista tiene algo”), pero al principio confunde, así que ve con tiento.

Lo siguiente: repetir sin copiar y pegar

Ya sabes que un programa decide. Lo que todavía no sabe hacer es repetir. ¿Y si quieres saludar a cien usuarios, o recorrer una lista de la compra entera? No vas a escribir cien veces lo mismo.

En la próxima entrega entran los bucles: cómo repetir un trozo de código tantas veces como haga falta sin copiar y pegar, y cómo no quedarte atrapado en un bucle infinito que cuelgue el programa.

Preguntas frecuentes

¿Cuándo uso un if/else if y cuándo un switch?

Usa if / else if cuando cada rama evalúa condiciones distintas o rangos (nota >= 9, nota >= 7…). Usa switch cuando comparas siempre la misma variable contra valores concretos y fijos (el día de la semana, un código de estado). El switch queda más limpio en ese caso, pero recuerda poner break en cada caso para que la ejecución no se cuele al siguiente.

¿Qué son las guard clauses y por qué se recomiendan?

Una guard clause es una comprobación al principio de un bloque que sale pronto si no se cumple un requisito, en lugar de anidar todo el código dentro de ifs encadenados. Evitan el famoso “código Hadouken” en forma de pirámide, dejan la lógica plana y legible, y reducen errores. Primero descartas los casos malos uno a uno y al final dejas la acción principal.

¿El operador ternario sustituye al if/else?

Solo para casos simples. El ternario (condición ? valorA : valorB) es ideal para asignar un valor u otro según una condición en una sola línea. Pero si la lógica tiene varias ramas o es enrevesada, un if/else normal se lee mucho mejor. Comprimir lógica compleja en ternarios anidados produce código ilegible.

El libro para esta entrega

Para fijar el control de flujo (condicionales, y los bucles que vienen ahora) con explicaciones suaves y para cero absoluto, te recomiendo Python para todos, de Charles Severance. Es claro, va paso a paso y no da nada por sabido, justo lo que necesitas en esta fase.

Este artículo contiene enlaces de afiliado.

Compártelo si te ha resultado útil.

¿Has sufrido alguna vez un buen “ayuuuken” de ifs anidados, propio o heredado? Cuéntame el caso más exagerado que hayas visto.

Y… en la próxima entrega, a repetir sin repetirnos.