El Programador En Su Laberinto

–Como hacer un mapa de un programa en ASM–

Uno de los muchos requisitos que los héroes de la antiguedad debían de cumplir para ser considerados como tales era el de poder orientarse en los mas intrincados laberintos mientras se enfrentaban a toda clase de trampas y monstruos que los habitaban. Y por supuesto en ningún juego de aventuras que se respete pueden faltar esta clase de retos, junto con sus guerreros feminoides y las interminables horas dedicadas a ganar puntos de experiencia. En el caso de la programación no solo en ASM sino en casi cualquier lenguaje de programación en el que se tenga que escribir código la situación es muy parecida a lo que se cuenta en el mito de Teseo y el Minotauro. Veamos todos estos parecidos.

Cuando uno comienza un programa, o al menos lo es en mi caso, tengo idea de lo que quiero hacer; pero no  dea de como va a funcionar. Igual que al recorrer los primeros cuartos de un laberinto uno sabe que tiene que llegar del origen al destino.

Conforme el programa crece se van agregando funciones y estructuras de datos que son mas o menos independientes entre si, igual que cuando uno va internándose en los primeros cuartos del laberinto.

Mas adelante comienzan los problemas cuando unas funciones comienzan a depender de otras, si bien esto ayuda a evitar código redundante hace que un error en las funciones mas primitivas afecten las mas nuevas, tal y como cuando para llegar a un cuarto en el laberinto hay que cruzar otros tantos.

Luego, comienza el problema de los identificadores, tanto nombres de variables como de funciones, es muy común olvidar a que procedimiento pertenece cada una y esto es especialmente peligroso con las variables locales pues puede haber cientos de variables diferentes con el mismo nombre pertenecientes a diferentes métodos; igual que cuando uno cree que todos los cuartos y pasillos del laberinto parecen iguales y recorremos una y otra vez los mismos lugares sin llegar a ninguna parte.

Finalmente, la estructura del programa se vuelve tan grande y enredada que es necesario regresar continuamente sobre las instrucciones ya escritas para saber lo que estamos haciendo tal y como ocurre en un laberinto cuando en verdad nos perdemos. Y es cuando estamos completamente perdidos cuando nos topamos cara a cara con el Minotauro.

El Encuentro con el Minotauro

Así es, cuando el programa se ha vuelto demasiado complicado en su estructura es cuando aparecen los errores mas peligrosos y resolverlos no es algo que se haga en un solo sitio, sino que casi siempre involucran recorrer muchos procesos diferentes repartidos en diferentes partes del programa a menudo separadas por miles de lineas de código. Igual que un verdadero encuentro con el Minotauro sería una mutua cacería entre dos depredadores donde luego de cada choque aquel que resultara mas lastimado huyera tan solo para recobrar fuerzas y volver a atacar a su oponente a traición.

Y eso es lo que hace tan diferente la resolución de problemas dentro de un programa tan dificil como una persecución dentro de un laberinto. Y a diferencia de la lucha en terreno despejado, para sobrevivir al combate en un laberinto no basta con saber pelear. Es necesario conocer bien el lugar. Saber donde se localizan los atajos, los sitios para esconderse y las trampas ocultas. Si uno sabe todo esto puede emboscar y acorralar al Minotauro para evitar que se escape o incluso engañarlo para hacerlo correr directo a ese precipicio que solo nosotros sabemos donde se encuentra. Por eso lo mas importante es conocer cada detalle del laberinto y bajo ninguna circunstancia perdernos dentro de él.

Dibuja un Mapa del Laberinto

Esto parece obvio; la pregunta es como demonios nos orientamos ahí dentro. De acuerdo con el mito griego, Teseo amarró el extremo de una larga madeja de hilo a la entrada del laberinto y conforme se internaba en este lo iba desenredando. De ese modo cuando quisiera regresar tan solo tenía que seguir ese hilo. Ahora, si Teseo hubiera tenido papel y lapiz probablemente pudo haber dibujado su propio mapa y marcado en este los lugares por donde ya había pasado. Y al igual, un programador necesita llevar su propio mapa del código en el que está trabajando. Hace mucho en este mismo blog hablé sobre este problema pero en esa época mi solución era desarrollar un editor de texto con funciones avanzadas de análisis del source code para ayudarnos con esta tarea; y aunque la idea aún no es por completo desechada es demasiado complicada para implementarla en el corto plazo. Por lo que aquí les presento un método para llevar un buen mapa de nuestro programa con tan solo una humilde hoja de cálculo.

Esta es la captura de pantalla de una hoja de cálculo común y corriente. La primera columna contiene el nombre del símbolo y las siguientes información sobre este, como por ejemplo su ancho en bits, el tipo de información que contiene y por supuesto una descripción de unas pocas palabras. Y cuando digo símbolo no me refiero nada mas a las variables, sino también al nombre de las funciones, etiquetas de salto, estructuras, constantes y cualquier otra cosa que pudiera ser nombrada dentro del programa.

El modo de usar esta hoja es muy simple, tan solo se sueltan escribiendo su código como siempre y el el momento que declaren una variable, programen alguna función o hagan referencia a alguna constante simbólica solo tienen que “darla de alta” en esta hoja de cálculo no solo con el nombre, sino su tipo de dato y algún breve comentario sobre la misma. Conforme el programa crezca van a necesitar información como el nombre exacto de un determinado identificador, sobre todo si están usando la infame Notación Hungara tan común en la programación para Windows o el orden en que una función recibe sus argumentos. No hay problema, tan solo hay que ordenar las entradas de la hoja de cálculo en orden alfabético para encontrar ese símbolo de manera rápida. Ahora veamos algunas de las ventajas que tiene este sistema:

• Evita duplicidad de variables.- Es muy común que cuando el programa crece demasiado aparezcan identificadores con nombres muy parecidos que hacen cosas completamente diferentes. Si hay una variable que ya hace algo que queremos hacer podemos encontrarla a la hora de “dar de alta” esta en la hoja.
• No mas errores de llamados de función.- Personalmente yo pierdo mucho tiempo buscando una y otra vez el lugar de declaración de esa función tan solo para ver detalles sobre el orden y tipo de sus argumentos, sobre todo cuando no recuerdo el nombre exacto. Esta hoja ayuda a encontrarlos sin tener que moverse en el código cada vez. Además de ser especiamente útil a la hora de llamar funciones externas como las del sistema operativo cuya documentación rara vez se encuentra en Ensamblador.
• Se evita el problema del hardcode y los ‘magic numbers’ sin enredarse aún mas.- Dicen los programadores mas experimentados que uno nunca debe de poner constantes numéricas dentro del código porque luego es mucho mas dificil hacer cambios, sin embargo el hecho de usar constantes simbólicas puede hacer que el código se vuelva mucho mas enredado y dificil de leer sobre todo para los principiantes. Podemos poner los nombres de estas constantes simbólicas junto con su verdadero significado numérico en la hoja y así siempre tendremos a la mano ambas informaciones mientras programamos. Esto es especialmente util cuando trabajamos con la API del Windows, DirectX o cualquier otro sistema que haga uso de nombres extraños para las constantes.
• Da una idea de la complejidad del programa.- Supongo que nadie se imaginaría que un simple Hola Mundo en Ensamblador para Windows iba a necesitar de ¡19 variables!. Con este sistema uno puede darse una idea de que tanto se ha complicado el programa y se tiene toda la información a la mano para simplificarlo.
• Tiene Disponibilidad Inmediata.- Esta es la mejor parte, pues no hay que hacer nada mas que abrir una hoja de calculo de Microsoft Excel, o si no les alcanza para su copia pirata de reforma usen Calc de OpenOffice. Y para moverse entre el editor de ensamblador y el organizador de variables no hace falta mas que oprimir la combinación de teclas ALT + TAB

Este sistema puede ser ampliado de muchas formas, por ejemplo pueden hacerse mas columnas con información sobre los símbolos y variables o guardar información sobre los archivos usados en los proyectos mas grandes. Solo recuerden que cada que ingresen un valor hay que reordenar todos los elementos para que sea mas sencillo encontrarlos cuando los necesitemos, mientras que en el editor de ensamblador no nos hará mas falta que las propias funciones de búsqueda e intercambio de texto para mantener el programa bajo control.

Bueno ya escribí demasiado, en la próxima entrada hablaré sobre una manera muy sencilla y de rápida implementación para comunicarse con un programa cuando el teclado y la pantalla no están disponibles. Por ahora mejor me pongo a escribir código y espero esta vez no perderme en él.