Академический Документы
Профессиональный Документы
Культура Документы
llActivateEjecutado
Beneficios:
Permite distinguir rpidamente los distintos alcances y tipos de variables y propiedades, por lo
que pueden convivir variables o propiedades del mismo nombre y distinto alcance o tipo (ej:
gdFecha y ldFecha)
Ayudan, en parte, a ver si un mtodo est bien encapsulado o si requiere mayor parametrizacin.
Como regla general, conviene usar siempre variables locales para mantener la encapsulacin de
la funcionalidad
Impide que se confunda una variable con un nombre de campo (lcClave y clave)
Ayuda a entender mejor el cdigo y lo que hace
Beneficios:
Permite distinguir rpidamente los distintos tipos de objetos
Ayuda a entender mejor el cdigo y lo que hace
o incluso cerrar la sesin de VFP si se usa para ejecutar, y luego ya se puede hacer el checkin o checkout.
Beneficios:
Evitar errores por "archivo en uso"
Evitar hacer checkin de partes del componente (proteger SCX sin su SCT, etc) si el SCM no usa
transacciones atmicas (todo o nada)
4. Sesiones de FoxPro
Recomendacin:
Evitar cambiar el directorio de una sesin de FoxPro que sea usada para modificar componentes,
o sea, no usar CD <directorio> o SET DEFAULT TO <directorio> si se modifican programas con
MODIFY o se ejecutan con DO.
Para distintos sistemas o programas en distintos directorios, es mejor usar sesiones
independientes de VFP (o sea, abrir un VFP para cada sistema)
Beneficios:
FoxPro suele cachear los programas y clases en la memoria, y al modificar en otra ubicacin se
podran guardar rutas invlidas o apuntando a otro directorio, sobre todo en las clases y forms
Beneficios:
LPARAMETERS crea parmetros Locales, o sea que se limpian automticamente al terminar el
mtodo y los mtodos que se llamen no vern las variables creadas, mientras que
PARAMETERS los crea Privados y seguirn siendo visibles al llamar a otros mtodos
Creando los parmetros nuevos al final, se garantiza la compatibilidad de las llamadas existentes
a este mtodo sin necesidad de pruebas de regresin, porque de otra forma habra que cambiar
todas las llamadas y volver a probar todo lo existente para verificar que no falle (pruebas de
regresin)
PCOUNT() lleva la cuenta de los parmetros del mtodo actual, mientras que PARAMETERS()
lleva la cuenta de los ltimos parmetros recibidos en cuelquier mtodo, incluyendo mtodos
Beneficios:
Definir las variables indicando la clase y la librera, permite usar Intellisense y acceder a la lista
de miembros de la clase al poner el punto (objeto.<miembros>), lo que ahorra tiempo
Usar nombres significativos facilita la compresin y claridad del cdigo, y el mantenimiento futuro
Asignar NULL a las referencias de objetos al terminar evita la referencias pendientes de tipo
7. Return
Recomendaciones:
No usar RETURN en medio los mtodos, sino slo al final de los mismos, ya que si no se rompe
el flujo natural del programa
Jams usar RETURN dentro de un ENDWITH! Deja referencias de objeto colgadas y al rato
genera el error C0000005
Agregar RETURN siempre al final de un mtodo o procedimiento, para poder elegirlo durante una
depuracin y poder salir del mtodo antes
Ejemplo:
LPARAMETERS tnValor
lnCodError = 0
IF tnValor <= 0
lnCodError = 1
ENDIF
RETURN lnCodError
Beneficios:
Los RETURN al final del cdigo permiten seguir el flujo del programa ms fcilmente
Se facilita la recoleccin de basura (liberacin de tablas y variables, etc) en un nico punto
Es ms fcil para depurar y permite saltearse todo el cdigo e ir directo al Return para salir del
mtodo (a veces viene bien al depurar)
8. Manejo de Errores
El control de errores es fundamental en cualquier aplicacin y no debe dejarse de lado o para el final, sino
que debe formar parte del diseo. Este artculo te ayudar a entender cmo funciona el Try/Catch y cmo
usarlo.
Recomendaciones:
Controlar los errores en todos los puntos clave del sistema y no ignorarlos
No dejar que FoxPro controles los errores con Abort-Retry-Ignore, porque es peligroso dejar esa
decisin al usuario, ya que normalmente "ignorar" para seguir adelante
Los errores se deben relanzar desde la capa de datos y negocio hacia la interfaz visual, donde se
muestran
Nunca deben mostrarse errores en una capa que no sea la Interfaz visual
Ejemplo:
TRY
lnCodError = 0
IF tnValor <= 0
lnCodError = 1
ENDIF
CATCH TO loEx
THROW
FINALLY
*-- Recoleccin de basura
ENDTRY
Beneficios:
Try/Catch permite el manejo estructurado de errores, y relanzarlos o tratarlos localmente
Finally permite recolectar la basura, tanto con o sin errores
Relanzar los errores de negocio o de datos permite reutilizar esas lgicas, encapsularlas y
testearlas de forma ms fcil y aislada
Al ser una estructura de control que envuelve al mtodo, facilita el flujo del programa y permite
salir de l con Exit, siempre por el final del mtodo
No permite usar RETURN dentro de la estructura (genera un error), lo que ayuda a estructurar y
disear mejor el proceso
haya un proceso central que solo gestione subprocesos (paso de datos entre ellos, gestin de
errores, etc) mediante llamadas a los mismos, donde el subproceso es el nico que implementa
el cdigo de la tarea necesaria
Si se tienen las tpicas hiper-libreras que lo hacen todo y que de tanta funcionalidad mezclada es
son difciles de mantener, una buena tcnica de encapsulacin, y muy simple, es reemplazar
mtodos con cdigo por llamadas a mtodos de libreras externas donde se mueva y adapte ese
cdigo. De esa forma se mantiene la API de la interfaz (los nombres de los mtodos) pero se
cargar mucho ms rpido porque ya no contendr todo el cdigo inicial, sino solo las llamadas.
Hay casos en los que es necesario redisear (cambiar la funcionalidad). No tener miedo de
hacerlo, ya que puede ahorrar ms tiempo que el que lleva mantener un cdigo espagueti
oBus.Funcionalidad_3()
*-- Funcionalidad 3
(cdigo con implementacin de la
funcionalidad 3)
Beneficios:
La separacin en capas permite el mantenimiento por separado y granular de los distintos
subsistemas
Esta separacin permite maximizar las posibilidades de reutilizar cdigo en procesos
desatendidos o para otros sistemas o relacionados al actual.
La separacin en libreras favorece su reutilizacin
La separacin en funcionalidades bien definidas que hacen una sola cosa en lo posible, no solo
favorece la reutilizacin, sino tambin que facilita su testeo de forma separada al sistema
mediante herramientas de Testing Unitario como FoxUnit
La creacin de mtodos "Gestores" unido a una buena nomenclatura funcional, facilita el anlisis,
comprensin y mantenimiento del sistema, evitando tener que entrar en cada mtodo para saber
lo que hace
En muchas ocasiones, el rediseo ahorra tiempo y mejora la calidad y mantenibilidad del cdigo
Ejemplo 2: Optimizacin
MESSAGEBOX( "Este es un mensaje!" )
Beneficios:
Cuanto ms simple es un mtodo, menos cdigo tiene y ms fcil de entender y mantener es
Menos cdigo implica menor probabilidad de errores
Los nombres de mtodos y variables que indican conceptos precisos y limitados, facilitan la
legibilidad del cdigo, su mantenimiento, su refactorizacin y su encapsulacin
Un cdigo fcil de ver y mantener, implica un menor costo de mantenimiento
Beneficios:
El hecho de realizar estas tareas de desarrollo (desarrollo, tests, refactorizacin) permite
maximizar la calidad desde el principio
La refactorizacin permite optimizar, depurar, limpiar y aclarar el cdigo que se est
escribiendosin cambiar la funcionalidad, de cara a facilitar el mantenimiento del mismo
Los Tests Unitarios automatizados permiten realizar comprobaciones automatizadas de procesos
o funciones importantes para el sistema y adems, como se mantienen en el tiempo, sirven
como pruebas de regresin para las siguientes versiones, lo que implica un gran ahorro de tiempo
de pruebas manuales
Donde personalmente comprob que TDD ahorra tiempo, es para la solucin de incidencias,
donde se sabe de antemano qu respuesta se esperaba de una funcin o proceso. En estos
casos, se hacen primero los tests para reproducir el problema o error (sale el test en rojo), luego
se hace la correccin del cdigo y finalmente se vuelve a ejecutar el test, que ya debe salir en
verde, lo que tambin permite comprobar que el test estaba bien hecho y que hace lo que debe.
12. Usabilidad
La usabilidad es la facilidad de poder usar un sistema.
Nota: Los efectos especiales que a algunos desarrolladores les gusta agregar a sus sistemas, a veces
terminan haciendo que la usabilidad del mismo empeore, por lo que se debe tener cuidado en esto.
Recomendaciones:
Permitir recorrer los controles con el teclado con un orden lgico y no catico (normalmente con
la tecla Tab o Enter), comenzando por arriba a la izquierda, e ir avanzando en sentido abajoderecha
Minimizar el uso de lneas y cajas 3D que tan de moda estuvieron con Windows 95 (1995)
En el diseo de las pantallas, realizar agrupaciones y separaciones funcionales por medio de
espaciado entre bloques, lo que sustituye a las lneas que antes se ponan por todos lados
En vez de usar cajas (shapes, lines) para agrupar controles, intentar usar una lnea de separacin
a modo de ttulo y espacios a izquierda, derecha y debajo que separen del resto
Alinear ttulos y campos, tanto verticalmente como horizontalmente, y usar el mismo espaciado
entre controles
Usar siempre el mismo tipo de alineacin de etiquetas: si se alinean a la izquierda, o a la
derecha ms cerca de los datos, hacerlo igual en todos los forms del sistema
Todas las acciones que se lancen desde el form deben poder hacerse con un control claramente
visible y pensado para tal accin (por ejemplo, un label no est pensado para eso, un botn de
comando s)
Evitar el bloqueo de la navegacin por la pantalla. Por ejemplo, no deberan mostrarse mensajes
modales (tipo messagebox) por el solo hecho de recorrerla. La navegacin debera ser libre.
Intentar utilizar mecanismos no bloqueantes para mostrar mensajes al usuario. Por ejemplo, la
lnea de estado inferior, un espacio especial de notificacin o una ventana que el usuario pueda
invocar con una tecla o botn.
Hacer un uso inteligente de los colores y las notificaciones grficas, como iconos o mensajes.
Por ejemplo, ante un error de ingreso por parte del usuario, se puede colorear el fondo de dicho
control para que el usuario lo vea y de esta forma no lo bloquea
Utilizar el control adecuado para el tipo de ingreso de datos o de seleccin requerido. Por
ejemplo, no usar varios checkbox para simular on optingroup
Disear dejando el espacio suficiente para los datos. El usuario debera poder ver el dato
completo sin necesidad de hacer scroll dentro de un textbox demasiado pequeo, por ejemplo, o
debera poder ver una opcin seleccionada completa en un combobox sin necesidad de
desplegarlo.
En los cuandros de dilogo o pantallas de accin que requieran alguna decisin del usuario,
poner siempre un botn para Cancelar o Salir, ya que algo como "Aceptar" solamente, no es una
opcin.
Aprovechar la posibilidad de redimensionamiento de los forms y hacer buen uso de la propiedad
Anchor, que permite redimensionar los controles
Evitar los colores chillones y optar por colores tranquilos (hay guas sobre esto)
Dado que hay sistemas en los que el usuario trabaja todo el da, el diseo y la usabilidad deben
considerarse como algo muy importante, y evitar elementos que distraigan su atencin
Ejemplos de diseo:
Beneficios:
Un recorrido ordenado por la interfaz, permite predictibilidad
Una interfaz clara minimiza los errores y aumenta la satisfaccin del usuario
Un buen diseo permite que el usuario pueda ser ms eficiente, pueda hacer las tareas en menor
tiempo y pueda distenderse
Nota final:
Esto no es todo, hay ms, pero esta es una buena base para poder trabajar en un equipo o en solitario, ya
que todas estas prcticas tienen como objetivo final el facilitar la comprensin y legibilidad del cdigo, su
encapsulacin, tambin minimizar el costo de su mantenimiento y maximizar la satisfaccin y eficiencia del
usuario.
Hasta la prxima!