Cambio de opinión: en algunos casos acepto el uso de null == $var

Hace un tiempo hice un extenso post comentando sobre el "difundido fanatismo" de algunos desarrolladores de usar al revés las condiciones de igualdad en un if , en mi opinión "contranatura", sin respetar como alguna vez nos enseñaron nuestros primeros docentes (ver artículos como "Código como documentación"):

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)
Sí, y solo sí, mientras tengas que alterar o agregar una condición que pueda generar este error, invierte la condición para estar cubierto ante cualquier distracción. Pero luego de hecho, fuera de producción, corrige el código, para clarificar su entendimiento.

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:

Silvi dijo...

un programador experto cometeria ese error (poner un = en lugar de 2 en un if)?? no creo...

proclamo dijo...

Si ya piensas en evitar ese error, simplemente no lo cometes.

Rafael Cano dijo...

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.

Isra dijo...

"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

Unknown dijo...

@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.

Diego dijo...

@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.

Unknown dijo...

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.

Unknown dijo...

@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.

AV4TAr dijo...

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).

Enrique Place dijo...

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 ;-)

Isra dijo...

O sea, que utilizamos una buena práctica (convenio de codificación) para evitar problemas cuando hacemos malas prácticas (hotfixes) :-P

Entradas populares