René Pacios

A lo largo de los años, los  que nos dedicamos al desarrollo de software vamos adquiriendo una serie de manías convenciones o normas que solemos aplicar en nuestro código. Muchas de estas reglas tienen su origen en las propias guías de diseño y codificación de muchos proyectos, como por ejemplo las famosas guías de desarrollo para AngularJs de John Papa,  .Net Framework Design Guides de Microsoft o las guías para contribuir con el proyecto .NET Core en github

Por otro lado, existen las que podríamos denominar de cosecha propia, pequeños detalles o manías que vamos perfeccionando con el tiempo y que, bajo el criterio del autor del código, resulta un enfatizador u optimizador de nuestro código.

Una de esas normas, que hasta recientemente consideraba una regla personal, y la cual llevo aplicando durante muchos años es la que quiero plasmar en este post. Se trata de una regla sencilla de implementar en las condiciones de los  flujos de control de nuestro código a la vez que sencilla. Veamos los siguientes 2 fragmentos de código:

Llegados a este punto, el código de ambos fragmentos muy parecidos y que evidentemente hacen lo mismo, pero ¿cuál crees que es la mejor opción? ¿Cual resulta más cómoda de leer?  Dado nuestro lenguaje natural, en la lengua de Cervantes, solemos leer “Si tamaño es 5”, ¿verdad?

Bien, vamos a plasmar el mismo código pero con un pequeño error de sintaxis, un error que cualquier programador podríamos cometer si no solemos trabajar con una única tecnología y solemos alternar entre lenguajes como Visual Basic o Delphi  junto con otros como JavaScript, Java o C#.

Como podemos ver en estos últimos 2 ejemplos, si utilizamos la forma de la constante a la derecha, en los lenguajes donde el operador = se utilice sólo para asignaciones nos puede jugar una mala pasada, dado que no se producirá ningún tipo de error ni de compilación ni de ejecución, pero el comportamiento no será el deseado, ¿por qué?, veamos que ocurre en el primer fragmento de código:

1. Se evalúa la expresión tamano=0, como es una asignación, almacenamos 0 en la variable tamano
2. Tras la asignación se evalua el resultado.
3. El resultado de tamano inicial se ha perdido por la asignación del 0
4. En muchos lenguajes como C o JavaScript la evaluación de un 0 equivale a false, por ese motivo siempre estaríamos ejecutando la rama del elese.

Este tipo de error, en ocasiones es resulta complejo de localizar, os lo digo por experiencia, recordad que los primeros post de este blog están en Visual Basic y JavaScript llevamo mucho tiempo con nosotros

Sin embargo el código del 2º fragmento provocará un error de sintaxis, o como mínimo nos saltará un error en tiempo de ejecución para los lenguajes interpretados, evitándonos con ello más de un error de cabeza.

Al principio del post, os comentaba que hasta hacía poco consideraba esta regla como personal aprendida a lo largo del tiempo, pues resulta que no, que es algo que existe por si misma, hasta le han puesto nombre, Yoda Conditions o Yoda notation, la verdad, que aunque no soy muy fan de Start Wars, el nombre mola

Espero que os haya gustado y os resulte de utilidad.

Nos leemos, René