Si … o no si ( To if or not to if )

Si … o no si ( To if or not to if )

¡Compártelo!Share on FacebookTweet about this on TwitterGoogle+Share on LinkedInEmail to someone
Resulta evidente la evolución de la informática a lo largo de los últimos años en su vertiente física, años después de su creación. La famosa ley de Moore se sigue cumpliendo de manera inexorable a lo largos de los años, sin embargo su faceta de desarrollo de software ha presentado una evolución desigual y esporádica. Por muchos es conocido lenguajes de bajo nivel como ensamblador que posteriormente evolucionaron a lenguajes más cercanos al lenguaje natural, como Pascal, C y más tarde a lenguajes de alto nivel (Java, .net, etc.)

Teclado

Resulta evidente la evolución de la informática a lo largo de los últimos años en su vertiente física, años después de su creación la famosa ley de Moore se sigue cumpliendo de manera inexorable a lo largos de los años, sin embargo su faceta de desarrollo de software ha presentado una evolución desigual y esporádica.

Por muchos es conocido lenguajes de bajo nivel como ensamblador que posteriormente evolucionaron a lenguajes más cercanos al lenguaje natural como C o Pascal y más tarde a lenguajes de alto nivel (Java, .NET,..)

Con el devenir de los años nuevos lenguajes han ido apareciendo, quizás uno de los avances más importantes en programación estructura o imperativa sea el desarrollo de los lenguajes orientados a objetos, otros paradigmas de programación han intentado destronar a la programación estructura y aún sin haberlo conseguido si han podido asentarse en ciertos nichos de programación, principalmente académicos y de investigación.

Sin embargo y a pesar de todos estos avances en la programación más tradicional persisten ciertas estructuras, en este artículo se tratará posiblemente la más conocida de todas ellas, el omnipresente if.

Estructura que de manera impertérrita ha estado presente a lo largo de las diferentes generaciones de los lenguajes de programación, tan asentada que pocos se atreven a cuestionarla, a pesar de que muchas veces cuestionar las bases ayuda a crear nuevos conceptos.

A estas alturas habrá quien se pregunte qué tiene de malo el if, porque debatir sobre algo que ha persistido de manera inexorable sin visos de vejez, posiblemente la costumbre, la aceptación de algo tomado falsamente como axioma o la aparente inocencia de una estructura tan simple sean la razón.

Un ejercicio muy práctico que pretende ilustrar la idea que presenta este artículo es revisar cualquier control de código fuente, en particular la sección de errores, y hacerse esta pregunta ¿cuántos errores he tenido por culpa de un if? Cuántos podría haber evitado por un if que debería haber quitado o agregado o modificado…?

Un acercamiento más detallado nos lleva a cuestionar hasta qué punto un if puede llegar a clarificar tanto el código escrito como el concepto lógico que pretende transmitir, incluso áreas de las matemáticas como la programación lógica abordan el tema de la condición con mayor profusión y detalle de lo que un lenguaje de programación puede llegar a permitir.

Ingentes cantidades de código llenos de if con más bien poco sentido oscurecen el código y lo hace ininteligible, aun a pesar de los denodados esfuerzos por parte del programador de estructurarlos en una extraña suerte de forma piramidal que pretenda transmitir coherencia cuando realmente el efecto real es el contrario.

Si bien es cierto que en algunas ocasiones es inevitable, a fin de cuentas a simplemente es mayor que b o menor, esto no es óbice para que en muchas otras ocasiones se abuse de manera sistemática de esta estructura, sobre todo a la hora del diseño de código, pocas veces hace falta crear estructuras complejas usando if, los actuales patrones de software proporcionan elegantes formas de escribir código basándose por ejemplo en el tipado.

Se han estandarizado a lo largo de los últimos años patrones Factory que proporcionan creación de objetos basados en metadadatos de los tipos o en interfaces comunes a los tipos creados, no es necesario en este caso discernir entre unos y otros, simplemente cada tipo es consciente de su propia naturaleza y puede actuar acorde a ella.

Un ejemplo más práctico lo tenemos en las pruebas de software, siempre se ha dicho que es imposible probar sistemáticamente una aplicación debido a la gran cantidad de variantes y posibles datos diferentes, a raíz de esto han surgido las métricas de software y diversas metodologías orientadas incluso algunas de ellas a las pruebas.

Si nos detenemos en las pruebas de caja blanca, un recubrimiento lógico implica el mapa de código de todas las posibles alternativas, mapa que se va construyendo sistemáticamente a medida que el código se bifurca, resulta obvio pensar en este caso que un mayor número de bifurcaciones produce un mayor número pruebas y por lo tanto una mayor posibilidad de error.

Estas bifurcaciones pueden ser eliminadas simplemente haciendo una inspección detallada del código, no solo de la bifurcación actual sino también del código previo, hecho muy importante ya que dará una visión más amplia del código y por lo tanto se podrán descubrir todas aquellas bifurcaciones no necesarias.

Muchas veces en el desarrollo de software la visión global se pierde con el tiempo, y como consecuencia la calidad del software disminuye, debido por ejemplo a decisiones tomadas con antelación que posteriormente no fueron revisadas, esta pérdida de visión provoca generalmente una limitación en los nuevos desarrollos, se desarrolla código nuevo sin inspeccionar código previo lo que podría proporcionar una valiosa información sobre bifurcaciones “heredadas” y que durante el desarrollo deberían ser tenidas en cuenta tanto para su eliminación como para ser consideradas en código posterior evitando ramificaciones innecesarias.

Esta eliminación generalmente provoca un efecto de arrastre sobre el resto del código, eliminando de manera recursiva más bifurcaciones en código previo, lo interesante de este asunto es el hecho de que muchas veces no se practica este ejercicio debido a los posibles problemas que podría conllevar y al hecho de repetir las pruebas de regresión, cuando realmente el código está siendo simplificado a nivel de pruebas y tanto las actuales como las futuras serán menores y más rápidas.

Firmado,

Yo, Arquitecto
Josu Uribe Sainz

 


 

Uso de cookies

Este sitio web utiliza cookies para que usted tenga la mejor experiencia de usuario. Si continúa navegando está dando su consentimiento para la aceptación de las mencionadas cookies y la aceptación de nuestra política de cookies. Más información sobre nuestras cookies, siga este enlace

ACCEPT
Aviso de cookies