Volver menú revistas Volver página anterior

El Amiga Me Encanta ha conseguido el permiso por escrito de IDG Comunications España para ofrecer los artículos de la revista Amiga World España.

N° 38 - Diciembre 1992

     LENGUAJES     

 

PRODUCTIVIDAD
EN PROGRAMACION

Por Rubén Colón

En mi artículo anterior, mostraba los lenguajes y herramientas a disposición del programador. En este artículo pretendo explicar como puede obtenerse mayor productividad de nuestros programas intentando que un mismo código pueda funcionar en varios ordenadores distintos y que este código sea lo más compatible posible con futura sversiones de un mismo sistema operativo.

Lo primero que debemos considerar al programar una aplicación, es tener bien clara la tarea que va a realizar esa aplicación, que opciones va a ofrecer y como va ser el interface de usuario (las pantallas, menús, etc. es decir, lo que va a ver el usuario de nuestro programa).


DISEÑAR LA APLICACION

Lo más práctico es escribir una especie de manual del programa, describiendo para que sirve cada parte e incluso un diagrama de flujo del programa. Si nuestro programa va a acceder o volcar datos a archivos, debe diseñarse su estructura para determinar que datos y en que orden van a aparecer en cada archivo. Finalmente, debe determinarse que variables son necesarias en el programa y de hacer falta, las estructuras de datos que el programa va a manejar. Aconsejo la simplicidad. Mejor realizar aplicaciones arriesgadas en sucesivas versiones.


ELECCION DEL LENGUAJE ADECUADO

Evidentemente, sería ideal conocer casi todos los lenguajes de programación para podernos adaptar al trabajo soliciado. Como esto está alejado de la realidad, es bueno conocer al menos tres lenguajes: uno para tareas de gestión, uno de bajo nivel para poder aprovechar los recursos de la máquina y otro orientado a tareas gráficas y de cálculo. Si nuestro programa está destinado a una de estas areas, todo va bien pero si nuestro programa tiene características de más de una, puede optarse por tres estrategias.

1) Dividir el programa en dos o más partes y escribir cada parte en un lenguaje distinto. Finalizado esto, realizar un programa principal que conecte las diversas partes.

2) Realizar un programa principal que llame a fuciones externas. Cada función se realiza con un compilador del lenguaje que vayamos a usar para cada tarea. Debe realizarse la tarea del "linkado" del programa principal con los módulos objeto (terminados usualmente en .obj o bien .o), que se hayan generado con cada uno de los lenguajes usados. PResten atención a que los obj sean compatibles para ser linkados entre si.

3) Si todo falla, se puede intentar emular las funciones que no se encuentran en el lenguaje elegido, con otras de realización propia o por llamadas a librerías de dominio público o del Amiga (por ejemplo, para intentar leer un gráfico IFF desde el Amiga Basic, puede escribirse una subrutina que lo haga o bien usar la librería EXTEND o la iff.library.

Si ganara dinero con el programa, no use un lenguaje que desconozca, haga esto en proyectos personales. Si piensa vender el programa para más de un tipo de ordenador, considere un lenguaje que sea similar en ambas máquinas y al que tenga acceso.


METODOLOGIA DE PROGRAMACION

Hay algunos consejos de orden práctico que pueden seguir o no hacerlo. Si los siguies, en la mayoría de los casos le harán la vida más fácil, así que allá van.

1) Tenga una idea clara del programa, pues no se puede programar sobre lo que no se sabe (por lo menos un mínimo). Debe documentarse antes de empezar un proyecto.

2) Sea consciente de que el programa va a ser usado por personas sin experiencia informática, debe prever el peor de los casos. Intente adpatar el programa al usuario, no el usuario al programa.

3) No escirba el manual. Los programadores documentamos nuestros programas pésimamente.

4) Documente abundantemente el código fuente, si no lo hace, corre el riesgo de no entender su propio código unos meses después de finalizarlo.

5) Facilite la lectura del código fuente: no escriba más de una instrucción por línea, indente el código, etc.

6) Programe modularmente. Ponga las tareas repetitivas en forma de funciones, use bucles y evite los GOTOs.

7) Aisle las funciones y partes del programa que sólo se puedan ejecutar en un tipo de máquina. Esto le simplificará la tarea de transportar el mismo programa de un tipo de ordenador a otro distinto, sólo deberá cambiar esas partes.

8) Pruebe sus funciones a medida que las hace, cuando termine de escribir el código fuente, tendrá más probabilidades de que el programa funcione.

9) Use funciones estándar, que tengan la misma sintaxis en distintas plataformas (tipos de ordenadores distintos con sus sistemas operativos como PC DOS, UNIX, Amiga OS, etc.). Para esto existen numerosos estándar como el ANSI en el lenguaje C. Use antes estas funciones que otras especfíficas del tipo de ordenador que realicen tareas equivalentes.

10) No realice llamadas directas a la ROM del ordenador.

11) No calcule lapsos de tiempo exactos con bucles, un porcesador más rápido hace que se vuelvan inexactos. Tampoco tenga al ordenador esperando con bucles, use funciones que no tengan al procesador ocupado.

12) No aproveche partes de variables o estructuras de datos que crea sin usar, puede que algún día se usen.

13) Si existen, use funciones para reservar la memoria y crear variables. SI precisa cambiar la longitud de estas variables no tendrá que modificar todo el programa.


LIBRERIAS PROPIAS

Si hay ciertas funciones que use con frecuencia, puede intentar reunirlas en lo que se conoce como una librería, que no es más que una reunión de varias funciones que han sido ya compiladas y que realizan determinadas tareas.

Esta opción es la que da más trabajo, pues si es usted un desarrollador en más d euna plataforma, debe crear la misma librería para cada una de ellas, cosa que puede ser un trabajo largo y tedioso.

Por otro lado, los beneficios que ofrece una vez acabado suelen compensarnos. Nuestra productividad se ve muy incrementada, pues: a) Reducimos el tiempo de compilado de nuestros programas, pues estas funciones ya están compiladas. b) Mayor fiabilidad de nuestro programa (si hemos probado estas funciones a fondo). c) Si cubren la mayoría de tareas que realizamos comúnmente, no debemos reescribirlas cada vez.


DINAMICA DE LA GENERACION DEL CODIGO EJECUTABLE

El proceso de generación del código ejecutable, va desde que hemos terminado el código fuente con un editor, hasta que obtenemos el programa que es directamente ejecutable por el ordenador. El primer paso consiste en escribir el código fuente del programa desde un editor externo o si el lenguaje que usamos lo tiene, desde su editor. Si aplicamos a este código fuente el compilador, obtenemos un fichero que recibe el nombre de código objeto (que suele terminar con la extensión .o o bien .obj), y a este debemos aplicarle un "linker" (enlazador), que lo transformará, si todo va bien, en un fichero ejecutable por el ordenador. Puede que estos nombres no le suenen.

el código fuente no es más que un fichero de texto que contiene las órdenes escritas en el lenguaje que hayamos elegido. El código objeto es el fichero resultane, de traducir el código fuente a un código más cercano al que el ordenador puede ejecutar. En él quedan sin rellenar las llamadas a subrutinas y funciones, que no estén definidas en el mismo código fuente. El "linker" rellena estas zonas y produce el código ejecutable, que es un fichero que el ordenador puede ejecutar directamente.


TRASPASO DE CODIGO ENTRE MAQUINAS

Para ilustrar como un programa que funcione en un Amiga puede funcionar en un PC compatible, anda mejor que un ejemplo práctico por pasos:

1) COn un editor de Amiga, genero el código fuente de mi programa con cuidado de usar unlenguaje con estándar como el C ANSI y de dejar aisladas las partes que sólo se ejcutan en el Amiga (manejo de pantallas, ventanas, etc.)

2) Lo compilo usando un compilador C ANSI y si todo va bien lo "linko" (enlazo) con las librerías que precise. Ya tengo el programa funcionando en el Amiga.

3) Si quiero aprovechar el código fuente, debo pasar el archivo de los discos en formato Amiga, a los de formato PC (que el PC pueda leer). No es necesario pasar el fichero ejecutable pues los formatos del código máquina de Intel (PC) y Motorola (Amiga) son muy diferentes y no funcionaría. Para traspasar el archivo debemos disponer de un disco formateado para PC y podemos utilizar diversas utilidades como el DOS-2-DOS, el CrossDOS (que en el Amiga 3000 y Workbench 2.1 va incluido) o alguna utilidad de dominio público. Estas utilidades cogen un fichero desde una unidad de Amiga y lo pasan a un disco formateado para PC. Hay que tener cuidado de que todos los caracteres ASCII sean los mismos en ambas máquinas (usen el filtro ASCII que hay en preferencias en el WB 2.1). Si disponen de una Bridgenboard pueden usar el comando AREAD para realizar esta tarea.

4) Entonces me voy al PC y edito el código fuente de mi programa original y reescribo las funciones que sólo funcionan en el Amiga, sustituyéndolas por sus equivalentes PC.

5) Compilo desde un compilador C en el PC que soporte ANSI.

6) Si todo va bien después de "linkarlo", obtendré el fichero ejecutable en entornos PC bajo sistema operativo DOS.

Si es usted un desarrollador en más de una plataforma,
debe crear la misma librería para cada una de ellas, cosa
que puede ser un trabajo largo y teidoso. Por otro lado, los
beneficios que ofrece una vez acabada, suelen compensar.

Ya dispongo del mismo programa para PC y para Amiga. Personalmente sulo usar una técnica para evitar tener dos códigos fuentes separados (uno para el Amiga y otro para el PC). Esta se conoce como compilación condicional, en la que uso las directivas #ifdef del C. Esto me permite separar dentro dle programa las partes que se compilarán y las que no si lo hago en un PC o en un Amiga, por lo que en un sólo fichero tengo ambos códigos.


CODIGOS DIFERENTES, DATOS IGUALES

En el peor de los casos, puede ser que nuestra aplicación deba ser rescrita desde cero si debe funcioanr en otro tipo de ordenador bien por no disponer de las herramientas adecuadas, por mala planificación o por que dé más trabajo modificar el código fuente que reescribirlo.

En estos casos, no todo está perdido, podemos intentar mantener la compatibilidad con los datos y ficheros de modo que podamos traspasarlos entre varios tipos de máquinas difernetes. En este caos, hay que prestar especial atención al modo en que ambas máquinas guardan los datos numéricos y las cadenas de caracteres. Nada más, espero que estos consejos les sean útiles. Si tienen alguna consulta, pueden hacerla a través de la revista Amiga World.


Volver menú revistas Volver página anterior