viernes, agosto 15, 2014

Reglas mínimas y buenas prácticas de programación

Por: Fernando D. Bozzo

Las reglas que se indican a continuación, son buenas prácticas de programación que sirven, no sólo para trabajar con control de código fuente, sino para toda la programación en general.

Aunque para algunos sea obvio, para otros no lo es tanto, así que es mejor explicar los motivos de esto.



¿Qué son y para qué sirven las buenas prácticas?


Las buenas prácticas no existen desde siempre, sino que se fueron desarrollando como resultado de la experiencia común 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 prácticas que minimizan la posibilidad de los mismos.

Otra ventaja de las buenas prácticas, es que tienen a facilitar el mantenimiento del código, 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 código de dos desarrollos sobre los mismos componentes (llamado merge), aumentando la posibilidad de que sea automático y no requiera intervención manual.


Buenas prácticas de programación


La siguiente lista de recomendaciones es lo mínimo que conviene tener en cuenta en todos los desarrollos, tanto trabajando en solitario como en equipo.



1. Convención de nomenclatura de variables (VFP)

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

Ejemplos:
Parámetros => tcCadena, tnNumero, tdFecha, tlBoolean, taArray, toObjeto
Variables Locales => lcCadena, lnNumero, ldFecha, llBoolean, laArray, loObjeto
Variables Privadas => pcCadena, pnNumero, pdFecha, plBoolean, paArray, poObjeto
Variables Publicas => gcCadena, gnNumero, gdFecha, glBoolean, gaArray, goObjeto



2. Convensión de nomenclatura de objetos (VFP)

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

Ejemplos:
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



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

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

CLEAR ALL
CLOSE ALL
(y ahora se puede hacer el checkin o checkout)



4. Cambio de changeset (Plastic/VFP)

Al igual que en el caso anterior, es conveniente hacer el CLEAR ALL / CLOSE ALL, pero además es conveniente revisar y refrescar la vista de Cambios Pendientes, ya que si hubiera archivos modificados, generaría un aviso.



5. Trabajo en ramas (SCM)

Regla de oro: Nunca se debe trabajar o modificar en la rama personal de otro usuario, ya que se le puede ocasionar una inconsistencia en el desarrollo. La rama de trabajo personal es como el maletín de cada uno, no se comparte y es actualizada por el propietario exclusivamente.

Si se quieren compartir ramas, se deberá hacer con ramas que no sean personales (como una rama de una tarea) y solamente se debe actualizar mediante merge o cherry pick, nunca manualmente.



6. Sesiones de FoxPro

Evitar cambiar el directorio de una sesión 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), ya que los programas se suelen cachear en la memoria, y al modificar en otra ubicación se podrían provocar problemas de ruta inválida sobre todo en las clases y forms.



7. Parámetros

Usar LPARAMETERS en vez de PARAMETERS y si hay que agregar parámetros a un método, agregarlos siempre al final, nunca en medio, que eso rompe la compatibilidad de los programas.

Ejemplo agregando nuevo parámetro "tnCosto":
LPARAMETERS tcNombre, tnEdad, tnCosto




Como todo, esta lista no es definitiva, pero al menos es una buena base para poder trabajar de forma "compatible" con otros desarrolladores.


Hasta la próxima!


1 comentario:

  1. Buenas tardes, amigos. Me parece importante incluir un link al sgte doc donde se indica cómo hacer un MAIN.PRG .
    Crear un proyecto FoxPro ¿por dónde comenzar?
    https://fdbozzo.blogspot.com/2014/01/crear-un-proyecto-foxpro-por-donde.html

    ResponderEliminar