Ir al contenido principal

Guerras de Código: kata WeIrD StRiNgS CaSe


En la entrada anterior, hablamos de Codewars, una plataforma online de código que transforma los desafíos de programación en un campo de batalla lleno de creatividad y aprendizaje. 

Hoy, vamos a poner en práctica lo que estuvimos comentando, resolviendo uno de los kata (ejercicios) que me pareció interesante llamado: "WeIrD StRiNg CaSe".

Si aún no estás familiarizado con este tipo de problemas, te cuento que este kata pertenece al nivel de dificultad intermedio aproximadamente y nos reta a jugar con las cadenas de texto de una manera peculiar. La idea es transformar un texto común en uno donde las posiciones pares de cada palabra se convierten en mayúsculas y las impares en minúsculas.

Por ejemplo:
    "Hola mundo" → "HoLa MuNdO"

El desafío no solo pone a prueba tu lógica y manejo de cadenas, sino también tu habilidad para dividir el problema en pasos más pequeños y abordarlos poco a poco. 

A lo largo de esta entrada, vamos a ver cómo resolverlo paso a paso utilizando C#, mientras comentamos algunas estrategias y trucos que pueden ser útiles en desafíos similares.

Así que, sin más preámbulo, leamos la letra del ejercicio:

Nota: A los efectos de continuar con los lineamientos de nuestro blog que está en idioma castellano/español, voy a transcribir la letra del ejercicio ya traducida del inglés. Recordá que la plataforma está en inglés, pero siempre podes traducir el contenido si te cuesta un poco este tema.

Letra del ejercicio

"Escribe una función que acepte una cadena (string) y devuelva la misma cadena con todos los caracteres de índice par en cada palabra en mayúsculas, y todos los caracteres de índice impar en minúsculas. 

El índice explicado es de base cero (zero-based), por lo que el índice 0 se considera par y, por lo tanto, ese carácter debe estar en mayúsculas. Además, debes reiniciar el conteo de índices para cada palabra.

La cadena proporcionada solo contendrá caracteres alfabéticos y espacios (' '). Los espacios solo estarán presentes si hay varias palabras. Las palabras estarán separadas por un único espacio (' ')."

Ejemplos:
  • "String" => "StRiNg"
  • "Weird string case" => "WeIrD StRiNg CaSe"

Primera aproximación: usando StringBuilder

Lo cierto es que cuando arranqué este ejercicio creí que sería más sencillo de ejecutar.. pero me llevé alguna que otra sorpresa sobre todo en la parte donde la cadena está separada por varias palabras por espacio ' '.

En mi primer "approach" claramente el test dio failed, así que fui elaborando y reciclando el código a medida que avanzaba.

Para empezar, se me dio por usar StringBuilder. Lo que sabemos que no va a cambiar del string, son los espacios. Este carácter debe ser concatenado a nuestro arreglo de caracteres de forma natural y sin modificaciones. Entonces usamos la función de Append() cuando se de esta condición.
if (caracter == ' ') ➔ hacemos miCadena.Append(caracter)
En caso contrario, tomando el 0 como punto inicial, convertimos los caracteres pares en mayúsculas y las impares en minúsculas. Para esta parte necesitamos una variable de "posición", ya que tenemos que operar con la posición de cada carácter para evaluar si es par o impar.

Es decir:
Si (pos % 2 == 0) { miCadena.Append(char.ToUpper(caracter)) } else { miCadena.Append(caracter) }

Hasta acá, todo bien. Ahora lo que nos resta definir, es que las veces que nos encontremos un espacio durante la iteración tenemos que resetear la variable posición para que considere que el siguiente carácter anuncia una nueva palabra y la misma debe comenzar con mayúscula, acorde a nuestro requerimiento.

Lo que nos da una posible primer solución válida:
static string ToWeirdCase(string s)
{
    StringBuilder sb = new StringBuilder();
    int pos = 0;

    foreach(char c in s)
    {
        if(c == ' ')
        {
            sb.Append(c);
            pos = 0;
        }
        else
        {
            sb.Append(pos % 2 == 0 ? char.ToUpper(c) :c);
            pos++;
        }
    }

    return sb.ToString();
}
Si lo verificamos en los test-cases de Codewars, pasa las validaciones correctamente. 

Alternativa usando LINQ

Ahora, el código cumple su cometido y aunque es eficiente, se ve muy extenso para lo que hace la función. Podemos tratar de refactorizar o simplificar nuestra función utilizando un poco de LINQ.

Para dividir la cadena en palabras, podemos usar .Split() tomando como separador el ' ' espacio.

    var palabras = s.Split(' ');

Ejemplo:
  • Entrada: "hola mundo"
  • Resultado: palabras= ["hola", "mundo"]
A continuación, podemos usar .Select() para manipular y convertir la colección.

Primera transformación con .Select(palabra => ...)

Se recorre cada palabra en el arreglo:
  • Para cada palabra, podemos aplicar otra transformación
  • Segunda transformación con .Select((caracter, índice) => ...)
Dentro de cada palabra, se recorre cada carácter junto con su índice.

Dependiendo del índice:
  • Si índice % 2 == 0 (par), el carácter se convierte a mayúsculas usando char.ToUpper().
  • Si es impar, el carácter se deja como está. Tal cual lo hacíamos en la primera parte.
Los caracteres transformados se concatenan de nuevo en una palabra con string.Concat.

Ejemplo (para la palabra "hola"):
  • Carácter h, índice 0 → Mayúscula → H
  • Carácter o, índice 1 → Minúscula → o
  • Carácter l, índice 2 → Mayúscula → L
  • Carácter a, índice 3 → Minúscula → a
Resultado: "HoLa"

Por último, usamos un string.Join() para combinar todas las palabras transformadas.

Esta es otra forma de hacer lo mismo.. pero de forma distinta y utilizando LINQ.

La función se vería algo así:
static string ToWeirdCase(string s)
{
    var palabras = s.Split(' ');

    var resultado = palabras.Select(palabra => 
        string.Concat(palabra.Select((c, i) => 
            i % 2 == 0 ? char.ToUpper(c) : c)
        )
    );

    return string.Join(" ", resultado);
}
Este enfoque es más declarativo y conciso que el uso de bucles explícitos. LINQ facilita las operaciones sobre colecciones con código más legible y expresivo aunque consume un pelín más de recursos.

Simplificando la función

Una de las maravillas de LINQ es que las soluciones que podés llegar a confeccionar, pueden ser extremadamente concisas. Hay gente que de verdad lleva LINQ a otro nivel, y una característica más allá del poder que tiene para trabajar con colecciones es que puede verse realmente estético.

Esa función de arriba puede simplificarase aún más, quedando como resultado un bloque como el siguiente:
static string ToWeirdCase(string s)
{
    return string.Join(" ", s.Split(' ')
            .Select(p => string.Concat(p.Select((c, i) => i % 2 == 0 ? char.ToUpper(c) : char.ToLower(c)))));
}
Y.. no sé, según mi opinión, se ve fantástico (y hermoso)..

Realmente podemos concluir que Anders Hejlsberg (creador de LINQ y arquitecto principal del equipo de desarrollo de C#) es un groso, tanto él como su equipo claro está.

Si te gustan este tipo de desafíos, te recomiendo explorar más katas en Codewars. En la plataforma existen miles de ejercicios, desde los clásicos 'Hola Mundo' hasta retos avanzados que ponen a prueba tu lógica y te van a hacer replantearte soluciones durante días.

Otros artículos

Principio de Responsabilidad Única (SRP) – SOLID explicado con ejemplos

Introducción a S.O.L.I.D En esta entrada, intentaremos abordar un nuevo ciclo de conceptos que tienen que ver sobre los principios SOLID , que son fundamentales en la programación orientada a objetos o POO . Estos principios fueron formulados, en principio, por Robert C. Martin , también conocido como " Uncle Bob ", con el objetivo de mejorar la mantenibilidad y escalabilidad del código de software. SOLID es un acrónimo que representa cinco principios de diseño: Single Responsibility Principle (SRP) – Principio de Responsabilidad Única Open/Closed Principle (OCP) – Principio de Abierto/Cerrado Liskov Substitution Principle (LSP ) – Principio de Sustitución de Liskov Interface Segregation Principle (ISP) – Principio de Segregación de Interfaces Dependency Inversion Principle (DIP) – Principio de Inversión de Dependencias Estos principios nos ayudan a crear software más ...

Open/Closed Principle (OCP) – SOLID explicado con ejemplos

Continuando con el repaso de los principios de S.O.L.I.D. que inició en el hilo anterior - si no lo viste hacé click acá  Principio de Responsabilidad Única (SRP) - vamos a ver el segundo en orden de aparición: Principio de Abierto/Cerrado (OCP por sus siglas en inglés). Definición Formal El principio OCP (Open/Closed Principle) establece que el código de una clase o un módulo debe estar abierto para la extensión, pero cerrado para la modificación. Esto significa que no se deben realizar cambios en el código existente cuando se requiere alterar alguna funcionalidad. En lugar de modificar el código existente, se debe crear una nueva implementación que extienda la funcionalidad. La única excepción a esto son los arreglos de bugs, donde está permitido modificar el código existente. Si se desea introducir una nueva funcionalidad, como la ordenación en un método existente, en lugar de modificar el código, se crearía una nueva implementación q...

Roadmap para Desarrolladores Backend en .NET en 2025

El mundo del desarrollo backend está en constante evolución, y mantenerse actualizado con las mejores prácticas y tecnologías es clave para seguir siendo competitivo en el mercado. Si estás buscando una guía clara y estructurada para mejorar tus habilidades en . NET backend , el sitio roadmap.sh ofrece un excelente punto de partida. Para esta entrada vamos a explorar lo siguiente: ¿Qué es roadmap.sh y por qué es relevante? El roadmap backend para .NET en 2025 Tecnologías y habilidades esenciales para backend a considerar ¿Qué es roadmap.sh y quién lo creó? roadmap.sh es una plataforma ampliamente reconocida dentro de la comunidad de desarrolladores. Fue creada por Kamran Ahmed, un Google Developer Expert y contribuidor en múltiples proyectos de código abierto. Desde su lanzamiento, la plataforma ha crecido exponencialmente, acumulando más de 300,000 estrellas en GitHub y una comunidad activa de...

Codewars

Como algunos ya saben, soy un gran entusiasta de las plataformas en línea dedicadas a la educación y al entrenamiento de habilidades, lo que podríamos llamar "gimnasios mentales". Hoy quiero presentarles, o tal vez recordarles, una de mis favoritas: Codewars, conocida también como " Guerras de Código " en español. Si aún no la conocían, los invito a explorarla. Y si ya la conocían, este es un buen momento para redescubrirla y sacarle más provecho. ¿Qué es Codewars? Codewars es una plataforma educativa en línea diseñada como un juego para entrenar habilitades de programación. fue fundada en noviembre de 2012 por Nathan Doctor y Jake Hoffner . La idea surgió durante una competencia de Startup Weekend ese mismo año, donde desarrollaron un prototipo que obtuvo el primer lugar. En la actualidad, Codewars es propiedad de Qualified , una empresa tecnológica que ofrece una plataforma para evaluar y entrenar habilidades en ingeniería de software. Con esta herramienta pod...

Principio de Sustitución de Liskov (LSP) – SOLID explicado con ejemplos

¿Qué es el Principio de Sustitución de Liskov? Imaginá que tenés un control remoto universal diseñado para funcionar con cualquier televisor. Si un nuevo modelo de TV no responde a los mismos comandos, el control deja de ser útil. El Principio de Sustitución de Liskov es como una garantía de que cualquier 'televisor' (o clase derivada) va a funcionar correctamente con el 'control remoto' (o clase base). El Principio de Sustitución de Liskov ( LSP ) es el tercer principio de SOLID , representado por la letra L y establece que: Los objetos de una clase derivada deben poder sustituir a los objetos de su clase base sin afectar el comportamiento correcto del programa. En otras palabras, si una clase hija hereda de una clase padre, cualquier instancia de la clase hija debería poder usarse en lugar de una instancia de la clase padre sin alterar la funcionalidad esperada. ¿Quién es Bárbara Liskov? Bárbara Liskov es una destacada científi...

Principio de Segregación de Interfaces (ISP) – SOLID explicado con ejemplos

El Principio de Segregación de Interfaces es otro de los principios SOLID y establece que: Una clase no debería verse obligada a depender de métodos que no utiliza .  En otras palabras, en lugar de crear una interfaz grande con muchos métodos, es mejor dividirla (segregar) en interfaces más pequeñas y específicas. Pero.. ¿Por qué? Obliga a implementar métodos innecesarios Si una clase solo necesita una "parte" de la funcionalidad de una interfaz, pero esta interfaz es muy grande, se va a ver obligada a implementar métodos que no usa. Esto es casi que inevitable si no buscamos la manera de separar mejor las responsabilidades. Imaginemos una interfaz IVehiculo que tiene los siguientes métodos: public interface IVehiculo { void Conducir () ; void Volar () ; void Navegar () ; } Si una clase Auto implementa esta interfaz, se ve obligado a definir métodos como Volar() o Navegar() , aunque un auto no vuela ni navega. public c...
Buy Me A Coffee