VFP: Gua de Buenas Prcticas de Programacin y recomendaciones

Por: Fernando D. Bozzo

Hace poco publiqu unas Reglas Mnimas de Buenas Prcticas de Programacin, orientadas principalmente

a las prcticas con el control de cdigo fuente que estbamos haciendo.

En esta ocasin voy a tomar parte de lo escrito all y a extenderme ms sobre esas y algunas otras, de

forma de tener una Gua ms completa respecto de la programacin en general con algunas cosas

especficas de FoxPro y en algunos casos con el por qu o en qu beneficia hacerlo, ya que personalmente

considero muy importante qu es lo que motiva a recomendar hacer las cosas de una forma determinada.

Las buenas prcticas no existen desde siempre, sino que se fueron desarrollando como resultado de la

experiencia comn de muchos desarrolladores y empresas dedicadas al desarrollo de software, como

Microsoft y otras.

En esas experiencias se han pasado muchas veces por situaciones conflictivas, que luego de haber

identificado fallos o problemas comunes, y luego de haber analizado los motivos que llevaron a ellos, se han

ido perfeccionando ciertas prcticas que minimizan la posibilidad de los mismos.

Otra ventaja de las buenas prcticas, es que tienen a facilitar el mantenimiento del cdigo, no solo por la

persona que lo hace, sino por otros, lo que permite "normalizar" la forma de hacer las cosas, bajar los

tiempos de desarrollo y maximizar la eficiencia.

Finalmente, el uso de estas normas minimiza los problemas y las diferencias a la hora de tener que mezclar

el cdigo de dos desarrollos sobre los mismos componentes (llamado merge), aumentando la posibilidad de

que sea automtico y no requiera intervencin manual.

Est detallada en la ayuda de FoxPro y en el MSDN de Microsoft

Resumen:

La primera letra define el alcance (local, privada, global)

La segunda letra define el tipo de dato (numrico, carcter, date, etc)

El nombre debe definir el concepto que representa

Ejemplos de nomenclatura:

Parmetros (t) => tcCadena, tnNumero, tdFecha, tlBoolean, taArray, toObjeto

Variables Locales (l) => lcCadena, lnNumero, ldFecha, llBoolean, laArray, loObjeto

Variables Privadas (p) => pcCadena, pnNumero, pdFecha, plBoolean, paArray, poObjeto

Variables Publicas (g) => gcCadena, gnNumero, gdFecha, glBoolean, gaArray, goObjeto

Ejemplos de buen uso conceptual:

ldFechaNacimiento

glUsuarioActivo

Qu son y para qu sirven las buenas prcticas?

1. Convencin de nomenclatura de variables (VFP)

Ejemplos de nomenclatura:

custom => cus_nombre

label => lbl_nombre

form => frm_nombre

checkbox => chk_nombre

editbox => edt_nombre

listbox => lst_nombre

spinner => spn_nombre

pageFrame => pgf_Nombre

page => pag_Nombre

commandButton => cmd_nombre

Ejemplos de buen uso conceptual:

txt_FechaDeNacimiento

cmd_CerrarFormulario

pag_ConfiguracionesDeUsuario

frm_PermisosPorUsuarioYGrupo

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

Est detallada en la ayuda de FoxPro y en el MSDN de Microsoft

Resumen:

Las primeras 3 letras definen el tipo de objeto

El nombre debe definir funcionalmente para qu sirve

Beneficios:

Permite distinguir rpidamente los distintos tipos de objetos

Ayuda a entender mejor el cdigo y lo que hace

Recomendacin:

Antes de hacer un checkin o un checkout de componentes, es conveniente limpiar el entorno para evitar

problemas:

CLEAR ALL

CLOSE ALL

2. Convensin de nomenclatura de objetos (VFP)

3. Checkin y checkout de componentes (SCM/VFP)

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)

Recomendacin:

Evitar cambiar el directorio de una sesin de FoxPro que sea usada para modificar componentes,

o sea, no usar CD o SET DEFAULT TO 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

Recomendaciones:

Usar LPARAMETERS en vez de PARAMETERS y si hay que agregar parmetros a un mtodo,

agregarlos siempre al final, nunca en medio o al inicio de los parmetros existentes.

Usar PCOUNT() en vez de PARAMETERS()

Ejemplo agregando nuevo parmetro "tnCosto":

LPARAMETERS tcNombre, tnEdad, tnCosto

lnParams = PCOUNT()

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

4. Sesiones de FoxPro

5. Recepcin de Parmetros en mtodos

externos al actual, lo que puede producir errores de evaluacin

Recomendaciones:

Definir siempre que sea posible las variables de objeto indicando la clase y librera de pertenencia

Usar nombres significativos, que indiquen claramente para qu sirven

Antes de liberar la referencia del objeto, asignarle NULL

Liberar siempre las variables de objeto con RELEASE, y no confiar en la limpieza automtica de

Fox, porque a veces queda la referencia en memoria

Usar variables de objeto en lugar de rutas de objetos tipo obj1.obj2.obj3.objN

Si se deben usar muchas referencias de objetos en un bucle, usar WITH objeto .. ENDWITH

Aunque no est documentado, en los parmetros definidos con "AS clase" para aprovechar

Intellisense, no es conveniente referenciar clases de libreras o programas externas, sino solo

clases nativas, ya que con las clases externas se puede provocar un error C0000005 fatal. Para

referencias clases externas es mejor usar el truco del IF .F. descripto en el ejemplo de debajo,

donde nunca se ejecutar su contenido, pero servir para usar Intellisense.

Ejemplo 1: Referencia de objeto por parmetro

LPARAMETERS toEntorno, toException as Exception, tnCod as Integer

IF .F. && Truco para no ejecutar, pero poder definir Intellisense

LOCAL toEntorno AS "Entorno" OF "LIB_ENTORNO.PRG"

ENDIF

toEntorno.EspacioMinimoDeDisco = 100 && MB

Ejemplo 2: Uso de With..EndWith de forma ptima

WITH THISFORM.pgfConfig.pagEntrada.txtContador

FOR I = 1 TO 1000

.VALUE =.VALUE + 1

ENDFOR

ENDWITH

Ejemplo 3: Uso de Referencias de objeto cacheadas en variables

LOCAL loPagEntrada AS Page

loPagEntrada = THISFORM.pgfConfig.pagEntrada

loPagEntrada.txtUsuario.VALUE = ""

loPagEntrada.txtPassword.VALUE = ""

loPagEntrada.chkDiasVigencia.VALUE = 15

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.), 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

6. Uso de referencias de objeto

objeto, cuya acumulacin puede provocar el error C0000005

Liberar las variables de objeto con RELEASE es ms rpido y seguro que el recolector de basura

de Fox, donde a veces quedan colgadas en memoria

Usar variables de objeto (ej: loPagEntrada) en vez de referencias de objeto largas (ej:

thisform.pgfConfig.pagEntrada) permite ganar velocidad de ejecucin por no requerir leer cada

objeto de la secuencia, adems permite mayor claridad en el cdigo y ocupar bastante menos

espacio, lo que hace que se pueda leer y entender ms rpido

Usar With..EndWith cuando hay muchas referencias de objeto o referencias dentro de un bucle

FOR o DO WHILE siempre es lo ms rpido, ya que el WITH cachea el objeto

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

muestran

Nunca deben mostrarse errores en una capa que no sea la Interfaz visual

Ejemplo:

TRY

lnCodError = 0

IF tnValor

Ejemplo 2: Cdigo de mltiples funcionalidades para

externalizar

*-- Funcionalidad 1

(cdigo con implementacin de la

funcionalidad 1)

*-- Funcionalidad 2

(cdigo con implementacin de la

funcionalidad 2)

*-- Funcionalidad 3

(cdigo con implementacin de la

funcionalidad 3)

Ejemplo 2: Cdigo externalizado como

funcionalidades independientes

oBus.Funcionalidad_1()

oBus.Funcionalidad_2()

oBus.Funcionalidad_3()

Ejemplo 1: Cdigo de una funcionalidad para

externalizar

*-- Consultar artculo

(Aqu estara todo el cdigo que

implementa la consulta, el control de

errores, etc)

Ejemplo 1: Cdigo externalizado como funcionalidad

independiente

oBus.ConsultarArticulo(lcCodArt)

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

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

Ejemplo 1: Cdigo para mejorar

If condicin1

Else

If condicin2

Else

If condicin3

Else

EndIf

EndIf

EndIf

Ejemplo 1: Cdigo mejorado

Do Case

Case condicin1

Case condicin2

Case condicin3

Otherwise

EndCase

Ejemplo 2: Comentario obvio

*-- Muestra un mensaje

MESSAGEBOX( "Este es un mensaje!" )

Ejemplo 2: Optimizacin

MESSAGEBOX( "Este es un mensaje!" )

Ejemplo 3: Comentario obvio

*-- Si lActivateEjecutado=.F.

IF NOT lActivateEjecutado THEN

...(cdigo)

Ejemplo 3: Comentario ms til

*-- Si no se ejecut el evento activate

IF NOT lActivateEjecutado THEN

...(cdigo)

En muchas ocasiones, el rediseo ahorra tiempo y mejora la calidad y mantenibilidad del cdigo

Recomendaciones:

Desarrollar con la simplicidad en mente

Evitar complejidades innecesarias

Si algo se complica, probablemente convenga separarlo en partes ms simples o usar un mtodo

gestor de procesos

Evitar los mega-procedimientos que hacen de todo, ya que suelen ser los ms difciles de

arreglar si fallan, o de mantener, pasado un tiempo

Usar nomenclatura clara que todos entiendan, y no "yo solo me entiendo", porque dentro de

varios meses ser "ni yo mismo me entiendo!"

Cuando se modifica un cdigo existente, siempre evaluar si hay algo mejorable o que pueda

escribirse de forma ms clara. Si se puede refactorizar, hacerlo en el momento; si se puede

mejorar, pero es algo complejo o que llevar ms tiempo, preparar una tarea posterior para

"mantenimiento preventivo" y hacerla lo antes posible (futuro cercano, no lejano:)

Usar los comentarios estrictamente necesarios, pero usarlos bien.

Los comentarios deben explicar brevemente la funcionalidad no-obvia a primera vista, de otro

modo, sobran y mejor no ponerlos

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

10. Desarrollo sencillo y tonto (KISS)

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

Recomendaciones:

Las tareas de un ciclo de desarrollo ptimo, sin un orden especfico, son:

Desarrollar la funcionalidad

Crear tests automatizados (siempre que aporte beneficios)

Refactorizar el cdigo para simplificarlo lo ms posible

Ejecutar los tests antes creados para verificar que no se haya roto nada.

El orden de estas tareas puede variar dependiento del paradigma de programacin que se est

usando. Por ejemplo, si se usa TDD (Test Driven Development o Desarrollo Orientado por Tests),

los Tests Unitarios automatizados es lo que se hace primero para generar lo que se conoce

como "contrato", y luego se realiza el desarrollo para cubrir esa funcionalidad (y cumplir con el

"contrato" funcional)

La refactorizacin es parte de la tarea de desarrollo y no una mejora independiente para una

etapa posterior o futura.

Crear Tests Unitarios automatizados para cualquier funcionalidad o mtodo donde el test aporte

valor, por ejemplo, para mtodos de clculo, de evaluacin de decisiones, de procesos y de

cualquier funcionalidad, por pequea que sea, cuyo mal funcionamiento pueda ser muy perjudicial

para el sistema. No tiene sentido hacer Tests sobre cada mtodo existente, porque hacerlos

tambin conlleva un coste, y se debe buscar un equilibrio.

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.

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.

11. Desarrollar, Preparar Tests, Refactorizar y ejecutar Tests

12. Usabilidad

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 abajo-

derecha

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:

Ejemplo 1: Mal diseo

No sera mejor permitir Cancelar?

Un claro ejemplo de lo que podra ocurrir si no se permite:

Ejemplo 2: Mal diseo

Cajas y cajas y cajas dentro de cajas...

Ejemplo 3: Buen diseo

Este diseo que permite navegar sin bloquear al usuario con mensajes modales. Rpidamente se pueden ver

los campos que tienen algn error (fondo rojo) y un mensaje en una zona especial indica el error ocurrido

ms inmediato. Adems el botn Guardar no se habilita hasta que est todo correcto, pero siempre se

puede Salir y abandonar el proceso. Un botn extra podra permitir ver todos los errores de validacin y

posibles sugerencias de solucin en un form aparte:

Ejemplo 4: Buen diseo

Observar a la derecha, un solo cuadro y 3 bloques de informacin separados por espacio, y un panel inferior

separado por la sola presencia de los 4 botones de comando. Todo el conjunto usando tonos pastel entre

vvidos y tranquilos, y muy amenos:

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

[Artculo] Para qu sirve? Por qu es necesario?

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!

13. Usa Control de Versiones

Nota final: