No sabía que esto existía pero me parece tan divertido como absurdamente necesario: las condiciones Yoda (o Notación Yoda). Es un estilo de programación en el que las dos partes de una expresión, normalmente condicional, están escritas al revés. Funcionar funciona, y es tan correcto como el orden normal, solo que resulta un poco más críptico y menos legible. 'if (42 == $valor) '. Se lee: "Si 42 igual al valor es...".
Esa forma bastante clásica de evitar errores comunes en el código. Básicamente, es usar el llamado(en C y derivados) l-value (simplificando una expresión) como primer valor en una comparación para evitar sobrescrituras accidentales de valores.
Y no es ni críptico ni menos legible, de hecho solía ser un indicio de gente con experiencia programando y ha tenido más de un dolor de cabeza depurando código.
Es muy fácil escribir un solo "=" en una comparación, y al ser una sintaxis válida es bastante difícil de detectar, excepto si compilas con -Wall que ahí si te grita el compilador, si es lo suficientemente moderno.
Así que resumiendo, es para evitar que se te escape un "if (x=2)" en lugar de "if(x==2)", ya que el primero asigna 2 a la variable "x" y el resultado de esa asignación es siempre correcto, y en el segundo se compara si "x" es igual a 2.
PS: Usa siempre un -Wall y no seas guarro, limpia todos los "warrings" de tu código.
PS2: Recuerdo cuando microsiervos era una web interesante.
#5 Eso de que es más legible es muy opinable. Entre los estándares de estilo de mis proyectos está la prohibición de usar notación Yoda por innecesaria y menos clara.
Porque si pones
if ($x=2) en lugar de if ($x==2) por error, [igualar, en lugar de comparar]
el software compila o se interpreta correctamente, no falla y tienes un problema porque has modificado un valor sin darte cuenta, pero si pones: if (2=$x)
el software peta en tiempo de compilación o en tiempo ejecución si es interpretado a la que pase por ahí, porque estas asignando un valor a una constante, y no da lugar a dudas y te permite corregir el error.
Y te evitas errores. Así de simple.
Otro artículo hecho por un chaval que no sabe lo que es un puntero.
editado:
Joder, he escrito esto sin leerme el artículo, y veo que actualiza el mismo con una explicación idéntica a esta.
#3 No se que decirte... he visto programas que nunca creerias.
Empecé a trabajar en una empresa donde la mitad de la plantilla habiamos terminado la carrera el año anterior, hacía 2 años o todavía estaban en el último curso... lo llamabamos "sexto de informática".
Eramos baratos y durante ese año la empresa escogía a los que valía la pena mantener y les subía el sueldo o la gente se largaba a pastos mejores... así que los novatos iban rotando.
Pues en ese ambiente, con actitud post-universitaria, he visto programar cosas dignas de estudio... de estudio de sicología.
Desde montar un sistema de busqueda por arboles balanceados cuando se podía hacer un "select"... porque le molaba al que lo hizo.
Existiendo subrutinas preferir usar GOTO y poner en variables de donde se procedía para poder volver con otro GOTO (en plan: IF V = 3 GOTO 2334 ELSEIF 4 GOTO 3344 ELSEIF 5... y poner V=5 antes del GOTO ha esta parte del código) repito, el lenguaje permitía subrutinas. Recuerdo a un colega depurando ese código (el que lo creo ya se había ido) habiendolo impreso en papel y repartido las hojas en una mesa, y yendo con retuladores fosforitos saltando de una hoja a otra para intentar seguir el proceso.
En fin, siempre he deseado saber como habían acabado esas mentes pensantes.
#8 Bueno, siendo novatos es normal, todos hemos escrito códigos estúpidos para lucirnos Recuerdo que hace años salió un meneo sobre el tema, pero sería complicado encontrarlo a estas alturas.
#3 No tuve el placer de hablar él, lo habian despedido poco antes de entrar yo, si vi el codigo funcionando, pero creo que era mas troll/gracioso que con mala intención...
Comentarios
Uf, vaya mierda de articulo
#1 El día que descubra que la notación polaca inversa se utilizaba y era práctica, va a flipar.
https://es.wikipedia.org/wiki/Notaci%C3%B3n_polaca_inversa
Pues sí #1, es una mierda de artículo.
Esa forma bastante clásica de evitar errores comunes en el código. Básicamente, es usar el llamado(en C y derivados) l-value (simplificando una expresión) como primer valor en una comparación para evitar sobrescrituras accidentales de valores.
Y no es ni críptico ni menos legible, de hecho solía ser un indicio de gente con experiencia programando y ha tenido más de un dolor de cabeza depurando código.
Es muy fácil escribir un solo "=" en una comparación, y al ser una sintaxis válida es bastante difícil de detectar, excepto si compilas con -Wall que ahí si te grita el compilador, si es lo suficientemente moderno.
Así que resumiendo, es para evitar que se te escape un "if (x=2)" en lugar de "if(x==2)", ya que el primero asigna 2 a la variable "x" y el resultado de esa asignación es siempre correcto, y en el segundo se compara si "x" es igual a 2.
PS: Usa siempre un -Wall y no seas guarro, limpia todos los "warrings" de tu código.
PS2: Recuerdo cuando microsiervos era una web interesante.
#5 Eso de que es más legible es muy opinable. Entre los estándares de estilo de mis proyectos está la prohibición de usar notación Yoda por innecesaria y menos clara.
#1 #14 #2 #12 #14 Yo lo uso siempre,
Porque si pones
if ($x=2) en lugar de if ($x==2) por error, [igualar, en lugar de comparar]
el software compila o se interpreta correctamente, no falla y tienes un problema porque has modificado un valor sin darte cuenta, pero si pones:
if (2=$x)
el software peta en tiempo de compilación o en tiempo ejecución si es interpretado a la que pase por ahí, porque estas asignando un valor a una constante, y no da lugar a dudas y te permite corregir el error.
Y te evitas errores. Así de simple.
Otro artículo hecho por un chaval que no sabe lo que es un puntero.
#15 Yo no lo uso nunca, y nunca lo he echado en falta.
#3 No se que decirte... he visto programas que nunca creerias.
Empecé a trabajar en una empresa donde la mitad de la plantilla habiamos terminado la carrera el año anterior, hacía 2 años o todavía estaban en el último curso... lo llamabamos "sexto de informática".
Eramos baratos y durante ese año la empresa escogía a los que valía la pena mantener y les subía el sueldo o la gente se largaba a pastos mejores... así que los novatos iban rotando.
Pues en ese ambiente, con actitud post-universitaria, he visto programar cosas dignas de estudio... de estudio de sicología.
Desde montar un sistema de busqueda por arboles balanceados cuando se podía hacer un "select"... porque le molaba al que lo hizo.
Existiendo subrutinas preferir usar GOTO y poner en variables de donde se procedía para poder volver con otro GOTO (en plan: IF V = 3 GOTO 2334 ELSEIF 4 GOTO 3344 ELSEIF 5... y poner V=5 antes del GOTO ha esta parte del código) repito, el lenguaje permitía subrutinas. Recuerdo a un colega depurando ese código (el que lo creo ya se había ido) habiendolo impreso en papel y repartido las hojas en una mesa, y yendo con retuladores fosforitos saltando de una hoja a otra para intentar seguir el proceso.
En fin, siempre he deseado saber como habían acabado esas mentes pensantes.
#8 Bueno, siendo novatos es normal, todos hemos escrito códigos estúpidos para lucirnos
Recuerdo que hace años salió un meneo sobre el tema, pero sería complicado encontrarlo a estas alturas.
#9 Por eso digo que no creo que el del futbol lo hiciese por malicia y que nadie lo entendiese, sino simplemente porque le parecía más divertido.
#10 Pero una cosa es querer lucirse y otra es cifrar los nombres de las funciones y de las variables
Pero todo puede ser.
Lo "mejor" que he visto en codigo dentro de una empresa era uno que codificaba todo como si de futbol se tratase.
Las variables eran futbolistas famosos.
Las funciones acciones de futbol.
Y cosas asi...
Int Ronaldo=6;
Chuta(Ronaldo, porteria)
...
Era imposible trabajar con eso si no eras el creador del código...
#2 Era imposible trabajar con eso si no eras el creador del código...
Supongo que esa era la idea de quien lo ideó.
#3 No tuve el placer de hablar él, lo habian despedido poco antes de entrar yo, si vi el codigo funcionando, pero creo que era mas troll/gracioso que con mala intención...
#3 Seguramente para él tampoco era fácil. O el software era pequeño y fácil conceptualmente, o el creador es un genio.
#2 Vaya, ni que hubiese buscado inspiración aquí:
How to write unmaintainable code
https://github.com/Droogans/unmaintainable-code
#12 Ostias buen manual jajaja