if ($variable == "valor")
Por lo que este orden nos permite hacer una redacción natural de la lógica que estamos codificando, es decir:
if ($edad == 30)
Se traduciría como
"Si la edad es igual a 30"
Por lo que actualmente hay una "seudo-moda" de hacerlo al revés,
if (30 == $edad)
Se traduciría como
"Si 30 es igual a edad"
Algo que, luego de haber pasado algunos años dando clases a distintos niveles de desarrolladores, empezando por personas con cero conocimiento del tema, siento que esta práctica no hace más que dificultar la lectura natural de las condiciones, y en consecuencia, ofuscar el código.
Amante de lo simple como soy (considero que el verdadero arte y esencia de la programación es hacer las cosas simples, no complejas), me opuse completamente a esta práctica, aún con los argumentos técnicos de que esta técnica podría salvarnos en caso de asignaciones accidentales del tipo:
if ($edad = 30)
Lo cual en PHP terminaríamos modificando el valor de $edad (porque estamos usando un solo "=" y no dos), algo que no sucedería si hiciéramos
if (30 = $edad)
De todas formas me pareció exagerado al extremo, cambiar algo que se hizo por años, desde los inicios de los tiempos, solo para cubrir esta "hipotética situación tan poco probable", ni que hablar que todo IDE respetable nos detecta este error y es fácil de ver y corregir.
Bien, suerte que gracias a los errores uno aprende y me pasó hace relativamente poco este error con consecuencias bastante importantes, por lo que voy a describir en qué situación SI sugiero esta práctica (no siempre, no con todo el código):
- Si por una razón extrema tienes que modificar código en producción
- y además no puedes usar un IDE que te asista, y tienes que usar un editor sin asistencia en la codificación (como el Editplus, Notepad++, etc)
De todas formas, lo veo complicado de hacer si no estás acostumbrado a ello.
Pero bueno, cuando me sucedió me hizo reconocer que había una situación muy específica que podría ser aplicable y útil, aún para una persona con experiencia como yo ;-)
¿Alguna vez te fue verdaderamente útil esta práctica? ¿alguna otra?
11 comentarios:
un programador experto cometeria ese error (poner un = en lugar de 2 en un if)?? no creo...
Si ya piensas en evitar ese error, simplemente no lo cometes.
Silvia, no sé que experiencia tienes programando, pero si es verdad qe esas cosas pasan más veces de la cuenta. Mas aún cuando como ha dicho Enrique no estaba con un IDE de trabajo en condiciones.
Ne te ha pasado al escribir un documento de texto, sin tener la corrección automática activada el que has pulsado dos veces la 'l' para porner por ejemplo llave, y la segunda ele no se ha impreso y hasta que no lo has leido en papel no te has dado cuenta del fallo.
Pues mas o menos es eso lo que cuenta Enrique y que le ha pasado, estándo en cliente y sin sus herramientas de trabajo cotidianas. La solución que propone es tomar su practica para evitar ese tipo de error, y luego mas tranquilamente reescribir el copdigo en su lugar de desarrollo.
"solo para cubrir esta "hipotética situación tan poco probable", ni que hablar que todo IDE respetable nos detecta este error y es fácil de ver y corregir."
Estoy de acuerdo en que adoptar un convenio de codificación sólo para evitar un error en concreto puede ser un poco exagerado, pero...
a) ¿Poco frecuente? No creas... además, cuando se comete, cambia mucho la lógica y además es difícil de detectar.
b) Los IDEs (al menos los que yo he utilizado, entre ellos NetBeans) no lo detectan porque poner un sólo $a = 30 es una sintaxis válida para una condición if.
No hay que defender ningún convenio de programación como si fuese una ciencia exacta, o peor, como si fuese una religión :-P
@Silvia, creo que es un error muy común de tipeo, no de lógica, por lo que tiene poco que ver con la experiencia. Aunque la experiencia también nos hace chequear 2 o 3 veces las cosas, pero el apuro/confianza nos traiciona.
@Isra, algunos IDEs detectan asignaciones dentro de condicionales y lo desaconsejan.
Yo particularmente defiendo $var == 'valor' , en el ejemplo que cita Enrique, editando en producción, deberiamos tener los errores ocultos, así que no se cuanto aporta utilizar 'valor' == $var , ya que estaría igual de dificil de localizar el error. Suelo editar en producción, y por SSH, por lo que mi 'IDE', en esos momentos, es el nano, un ose acostumbra a cheaquear mucho más que confiar en lo que me sugiera o advierta una IDE avanzada o algún standard.
@Silvia: no tiene nada que ver la experiencia en esto.
@Isra: quizás deberías actualizar el NetBeans. Actualmente trabajo con la versión 6.7.1 y el IDE siempre advierte cuando dentro de una condición hay una asignación. Si bien es código válido el IDE solo avisa cuando estás programando.
@Adrian Ramiro: cuando se habla de "producción" se debe tener un cuidado especial, y no por el hecho de que "se vean los errores de programación impresos en pantalla". No pasa por eso.
Hay que tener especial cuidado porque son los datos reales.
Imaginate esto:
if($a = 50) {
grabarEnBaseDeDatosDeProduccion($a);
}
Se hizo una asignación cuando debería haber sido una comparación, y por este tonto error se grabó en la base de datos.
Por eso mismo Diego, que lo que acostumbro a hacer cuando edito algo en producción es chequearlo y recheaquearlo. Me da la sensación que adoptar otra manera de escribir solo por si me equivoco nos da una falsa sensación de estar cubiertos frente a algunos errores.
@Silvia.
En verdad que es un error muy común, sin importar la experiencia del programador.
Y debido a que es sintaxis valida para el lenguaje es aún mas díficil de identificar pues uno siempre se va por corregir la lógica asumiendo que la sintaxis esta bien.
Es complicado para alguien que esta acostumbrado a hacer if($a==10) a pasar de forma expresa a if(10==$a), ya que si uno va a hacer esto expreso indica que se está fijando en ese error adrede. No le veo mucho sentido.
Diferente sería que siempre hagamos el if(10==$a).
Muy buenos aportes todos! ;-)
Una aclaración: lo que quise decir, luego del post original donde decía que no estaba en absoluto de acuerdo con la práctica de invertir las condiciones de igualdad, me enfrenté a un hecho de la realidad que me hizo pensar que -por más experto que sea uno- puede cometer este tipo de errores... aún por primera vez!
Nuevamente, no tengo pensado cambiar mi práctica, la única forma de que sirva es hacerlo siempre, si lo haces de forma pensada, es lo mismo que controlar dos veces los "==", y no tienen sentido.
El post apunta a "abrir la mente a las posibilidad" porque la realidad es mucho más rica y variada de lo que podemos imaginar ;-)
O sea, que utilizamos una buena práctica (convenio de codificación) para evitar problemas cuando hacemos malas prácticas (hotfixes) :-P
Publicar un comentario