Condicionales Yoda

Publicado el 18 de agosto de 2010
Yoda Conditional

Yoda Conditional

“Condicionales Yoda” – usar if(constante == variable) en vez de if(variable == constante), como if(4 == foo). Porque es como decir “Si azul es el cielo” o “si alto es el hombre”.

Usar condicionales al estilo Yoda es común en lenguajes que usan == y =. Si se escribe la constante del lado izquierdo de la expresión, el compilador genera un error si se usa = en lugar de == para chequear la igualdad. Algunos incluso recomiendan hacer esto. Es un error común al intentar comparar dos valores olvidarse uno de los signos de igual, asignándole a la variable de la izquierda el valor, en vez de compararlos.

De todas formas hay alternativas más sanas a este tipo de errores como las advertencias de los compiladores (o IDEs) o tests unitarios…

El conocimiento en este post fue adquirido en StackOverflow, una de esas herramientas que se ha vuelto casi imprescindible para los programadores. No parece que hubieran pasado dos años desde que Joel Spolsky y Jeff Atwood unieron sus fuerzas en esta comunidad. Así como se aprende mucho de distintas tecnologías, metodologías y experiencias, también aprendemos éstas cosas.

Desde ese mismo post, comentario incomparable del usuario – mmyers

Isn’t “Yoda Programming” where you never handle exceptions? Because, you know, there is no “try”

La pregunta que detonó éste y otros conocimientos importantes del estilo fue:
New programming jargon you coined?

8 comentarios en este post

Feed de comentarios
  1. Avatar

    Alejandro Segovia 18 agosto. 2010 - 13:42

    Recuerdo leer de los Condicionales Yoda en su momento en Stack Overflow también.

    Una cosa que quería mencionar es que como tu decías, Fernando, resultan muy últiles en lenguajes donde podes convertir implicitamente cualquier variable a bool (C, C++, Python), sin embargo, en lenguajes más burocráticos (como Java), hacer algo como:

    int a;
    if (a = 1) { /* algo */ }

    también es un error de complación, ya que “a” no es de tipo boolean.

    Firefox 3.6.6 Mac OS
  2. Avatar

    Mario 19 agosto. 2010 - 20:09

    Especificamente en el caso de Java, las condicionales Yoda te pueden ayudar a eliminar código y hacer más claro lo que se está haciendo. Por ejemplo:

    String s;
    
    if (s != null && s.equals("loquesea"))
    

    vs.

    if ("loquesea".equals(s)) // No es necesario validar el null
    

    Otro caso en el que pueden ayudar a la legibilidad es en las “escaleras if-else” (siendo que Java no tiene un case para Strings:

    if (“uno”.equals(s)) {

    } else if (“dos”.equals(s)) {

    } else if (“tres”.equals(s)) {

    }

    En este caso el énfasis está en el valor con el que estás comparando. De la otra forma el valor con el que comparas queda más escondido entre los paréntesis.

    Creo que no es para todos los casos pero sí que tiene sus usos.

    Google Chrome 5.0.375.55 Mac OS
  3. Avatar

    Bng5 19 agosto. 2010 - 21:25

    ¿Vos qué decís? ¿Entro a StackOverflow para compartir la “Programación orientada a IF’s”, “Jenga GUI” y la “Programación mística”?

    Firefox 3.6.8 Ubuntu
  4. Avatar

    Damián Lezama 13 septiembre. 2010 - 20:35

    A mí no me gusta para nada, salvo que tengas que modificar algo que está todo escrito así o ese sea el code convention de tu empresa/grupo/etc. Lo del test unitario… los tests no necesariamente te lo agarrarían siempre, te la podés comer igual, ni que hablar si el error lo cometés al codificar el test 😀

    Los warnings ni hablar, warnings a full y warnings as errors, siempre. Esto no es así por defecto en los compiladores por acción del lado oscuro 😛 Justo el otro día un warning as error me saltó por esto, de burro tipeando nomás porque por suerte nunca tengo que usar ningún lenguaje donde comparar no sea == Pobres los que tienen que alternar entre lenguajes, están en el horno!

    Muy bueno el blog che, lo descubrí hoy.

    Internet Explorer 8.0 Windows 7

Dejar un comentario

Notificarme los nuevos comentarios por correo electrónico. Tambien puedes suscribirte sin comentar.

Toasty!