Cómo corregir el bug del bucle for en C#

Resumen

Resolver un bug en un bucle for combinado con un switch es uno de esos momentos donde la lógica de programación se vuelve tangible. Aquí verás cómo corregir el conteo de iteraciones en un proyecto de Blackjack en C#, por qué existen mil formas válidas de solucionar el mismo problema y qué retos avanzados puedes asumir para llevar tu código al siguiente nivel.

¿Por qué el bucle for consume créditos al entrar al menú?

El problema aparece cuando cada vuelta del bucle for descuenta un crédito, incluso cuando el jugador solo está navegando el menú sin jugar una ronda real.

Al entrar al switch, escribir 21 y ejecutar break, el flujo sale del switch, vuelve al for e incrementa el contador. El menú aparece de nuevo, y ahí ya se gastaron dos unidades del bucle por una sola partida. Cobrar créditos solo por estar en el menú no tiene sentido.

¿Qué hace exactamente la sentencia break dentro de un switch? Termina la ejecución del caso actual y devuelve el control al bloque que contiene el switch, en este caso el for, que entonces incrementa su contador.

¿Cómo corregir el contador con i = i - 1?

La solución propuesta es simple: cuando el jugador entre al menú sin haber consumido una ronda válida, restar uno al contador con i = i - 1. Así, la iteración no penaliza al usuario por navegar.

Es una corrección minimalista que respeta la estructura del for y evita reescribir toda la lógica. No es la única vía: en programación existen cientos de formas de resolver el mismo problema, y esa es una regla del oficio.

¿Cómo se prueba que el bug realmente quedó resuelto?

Todo código necesita pruebas. Pensar que algo funciona no equivale a haberlo verificado.

En la prueba se compraron cinco créditos y se jugaron cinco rondas completas de Blackjack. El flujo fue así:

  • Ronda 1: el jugador obtiene 10, el dealer 17, pierde.
  • Ronda 2: el jugador obtiene 4, el dealer 21, pierde.
  • Ronda 3: el jugador obtiene 7, el dealer 13, pierde.
  • Ronda 4: el jugador planta y pierde.
  • Ronda 5: el jugador pide carta, suma 23, se pasa de 21.

Después, con dos Platzi coins, se jugaron exactamente dos rondas y el contador respetó el presupuesto. El bug quedó resuelto.

¿Por qué siempre hay que probar el código después de corregirlo? Porque una solución teórica puede tener efectos colaterales. Solo ejecutando el flujo completo confirmas que el comportamiento real coincide con el esperado.

¿Qué es código educativo y por qué no sigue best practices?

El código de este proyecto es educativo, no productivo. Está diseñado para enseñarte cada condicional, cada elemento de flujo y cómo combinarlos entre sí.

Las best practices en C# existen porque la industria busca estandarización, y los design patterns funcionan como una navaja suiza: un conjunto de pasos probados para resolver tipos específicos de problemas. Pero antes de llegar ahí necesitas dominar programación orientada a objetos y .NET, que te permitirá escribir código backend.

Si resolviste el bug de otra forma, eso es una buena señal. Significa que estás pensando como programador.

¿Qué reto avanzado puedes resolver al terminar el curso?

El ejercicio final tiene tres niveles, y todos se construyen sobre lo que ya viste.

  1. Cuando el jugador venza al dealer, salir del juego, limpiar la terminal y reiniciar con el mensaje: "Welcome to Platzi Casino, how many Platzi coins do you want?".
  2. Cada vez que ganes una ronda, recuperar el Platzi coin apostado, ya que cada ronda cuesta uno.
  3. Permitir que el jugador defina cuántos Platzi coins apuesta por ronda. Si compras 1,000 y apuestas 100, ganar te da 200 y perder te resta 100.

Tienes todo el conocimiento necesario para lograrlo: variables, condicionales, bucles, switch y manejo de entrada por consola.

¿Qué viene después del curso de introducción a C#?

La ruta natural es programación orientada a objetos, el siguiente paso una vez dominada la base de C#. Después puedes saltar a .NET para escribir backend, o llevar la lógica de este Blackjack a un entorno gráfico usando Unity, el motor de videojuegos que comparte muchísima lógica con lo que acabas de programar.

De terminal puedes pasar a la web, a videojuegos o a aplicaciones empresariales. La elección depende de qué te emocione más construir.

¿Te gustaría que el próximo paso sea programación orientada a objetos en C# o una versión de Blackjack con gráficos en Unity? Cuéntame en los comentarios y comparte tu versión avanzada del código en un video o screenshot.