Convenciones para nombrar objetos
Las primeras tres letras del nombre de un objeto deben ser
utilizadas para indicar el tipo del objeto.
chk – Check box
cbo – Combo box
cmd – Command button
cmg – Command Group
cnt – Container
ctl – Control
cus – Custom
edt – Edit box
frm – Form
frs – Form set
grd – Grid
grc – Grid Column
grh – Grid Column Header
img – Image
lbl – Label
lin – Line
lst – List box
olb – OLE Bound Control
ole – OLE Object como un ActiveX
Control
opg – Option Group
pag – Page
pgf – Pageframe
sep – Separator
shp – Shape
spn – Spinner
txt – Text box
tmr – Timer
tbr – Toolbar
Normas para el código fuente
Utilice abundantes
espacios en blanco. Hará más legible su código.
Utilice
tabuladores, en lugar de espacios para indentar.
Los comandos y
funciones de Visual FoxPro deben escribirse en mayúsculas y con la totalidad de
sus letras, el resto del código debe estar escrito con combinación de
mayúsculas y minúsculas. Mantenga líneas cortas, tanto como sea posible, para
evitar desorden (line wrap) durante la impresión. Si una línea de código, ocupa
físicamente más de una línea, utilice las expresiones de unión como primer
carácter de la línea siguiente. Las expresiones de unión son del tipo +, AND,
OR, NOT, etc. Recuerde además, que la línea debe ser tan válida como si fuera
una sola línea. Coloque un espacio antes del punto y coma.
Ejemplos de malas separaciones de líneas
lcCommand = "Hoy es Miércoles, 16 de Octubre de
2003" + ;
"Son
las 2:00 PM"
IF
ldBeginDate >= DATE() OR ;
ldEndDate >=
DATE()</pre>
Ejemplos de buenas separaciones de líneas:
lcCommand = " Hoy es Miércoles, 16 de Octubre de
2003" ;
+ "Son las 2:00 PM"
IF
ldBeginDate >= DATE() ;
OR ldEndDate >= DATE()
Por lo visto, cada uno combina las mayúsculas y minúsculas
de forma diferente. Aunque no existe vía correcta o incorrecta en este aspecto,
si hay algunas normas que ayudan a la legibilidad. Además, utilice expresiones
CASE en lugar de IF, cuando parezca que se pueden agregar posteriormente más
opciones, incluso si existen sólo dos opciones en el momento en que es escrito
el código o, para liberarse de las instrucciones IF, ELSE, IF. Separe cada CASE
por una línea en blanco. El comentario para el CASE debe ir por debajo del
mismo.
Forma incorrecta:
DO CASE
* Este es el
comentario para el caso 1
CASE lnCount = 1
lcRetVal =
"Uno"
* Este es el
comentario para el caso 2
CASE lnCount = 2
lcRetVal =
"Dos"
* Este es el
comentario para otherwise
OTHERWISE
lcRetVal =
"Otro"
ENDCASE
Forma correcta:
DO CASE
CASE lnCount = 1
* Este es el
comentario para el caso 1
lcRetVal =
"Uno"
CASE lnCount = 2
* Este es el
comentario para el caso 2
lcRetVal =
"Dos"
OTHERWISE
* Este es el
comentario para otherwise
lcRetVal =
"Otro"
ENDCASE
Trate de evitar
macro sustitución. A veces la macrosutitución es la única vía para lograr algo.
Asegúrese de documentar, por qué utiliza macrosustitución y cuál es el
propósito del código. En la mayoría de los casos, la macrosustitución hace que
el código sea menos legible. Utilice la función EVALUATE(). Si es posible, pero
nuevamente los comentarios son importantes para ayudar a leer el código.
Evite utilizar STORE.
Utilice “[]” en
lugar de paréntesis en los arreglos. Así, el código es más legible.
Coloque espacios
entre los operadores matemáticos. Esto mejora la legibilidad.
Utilice paréntesis
cuando llame métodos o funciones, incluso, si no pasa ningún parámetro.
Evite el uso de m.
a la izquierda del signo igual. Esto mejorará el rendimiento.
Al concatenar
cadenas, coloque la variable a la izquierda del signo +. Esto mejorará el
rendimiento.
Normas para comentar código
Los comentarios son parte importante de cualquier
aplicación. Utilícelos abundantemente. Los comentarios deben explicar por qué
se han hecho algunas cosas e indicar cuáles son las líneas de código que están
afectadas. Debe explicar solamente cómo se hizo algo, en caso de estar
utilizando complejos algoritmos o cálculos.
No emplee comentarios al final de las líneas con
&&. Cada comentario debe ocupar una línea propia.
Encabezados de programa, método y procedimiento
Los encabezados de programa, método y procedimiento deben
indicar el nombre de la rutina, la fecha en que fue creada originalmente, el
autor y una descripción del objetivo del procedimiento o método. En caso de
existir parámetros y valores devueltos, incluya una descripción de los mismos.
Para los métodos, incluya la jerarquía de objetos.
Ejemplo 1:
*********************************************************
* Método........: frmQueue.cmdNext.Click
*
Descripción...: Displays the next item in the selected queue
*
Fecha.........: 01-Oct-2001
* Autor....
....: Fred Flintstone
*********************************************************
*
Modification Summary
*
*********************************************************
Ejemplo 2:
*********************************************************
*
Función......: CalcIntrest
*
Descripción...: Calculate the interest in dollars on the loan
*
Parámetros....: tnBalance: Required: The balance amount
* : tnRate:
Required: The interest rate to apply
*
Devuelve......: Numeric: The dollar amount of the interest
*
Fecha.........: 01-Oct-2001
*
Autor.........: Bullwinkle J. Moose
*********************************************************
* Modification Summary (Resumen de modificaciones)
*
********************************************************
Comentar modificaciones
Es importante poner comentarios al hacer modificaciones para
saber cuáles fueron las modificaciones realizadas, y por qué las realizó. La
sección Modification Summary (Resumen de modificaciones) en el encabezado
explicará por qué, cuándo y por quién fueron realizadas las modificaciones. En
cada lugar del código, donde fue realizada una modificación, debe comentar el
código viejo e indicar cuál es el código nuevo que fue añadido. Cada
modificación debe ser numerada. Los cambios pueden ser borrados después de un
año; pero el Resumen de modificaciones debe permanecer.
*********************************************************
*
Modification Summary
*
* /01
05-Oct-2001 George Jetson
* Changed
interest calculation to include a date range factor.
* /02
10-Oct-2001 Tennessee Tuxedo
* 1. Added
code to handle interest on widgets. The calculation is different.
* 2.
Changed the return value from numeric to character.
*********************************************************
*/01 lcNote
= "This is the old line commented
out "
*/01
lcNote
= "This is the new line of code.
"
*/02-1
lnInterest = a * b
*/02-1
lnInterest = lnInterest / 43
*/02-1 -
Begin - Multiple lines are being added, so indicate they start here
IF
UPPER(tcIntType) = "WIDGETS "
lnInterest = a * c
ELSE
lnInterest = a * b
lnInterest = lnInterest / 43
ENDIF
*/02-1 - End
Las líneas de comentario deben indentarse al mismo nivel del
código.
Este ejemplo es incorrecto:
IF lnTotalInterest = 0
*/01 � Begin
FOR lnCount = 1 TO lnTotal
lnTotalInterest = lnTotalInterest +
laLoans[lnCount, 2]
ENDFOR
*/02 �
End
ENDIF
Este ejemplo es correcto:
IF
lnTotalInterest = 0
*/01 � Begin
FOR lnCount = 1 TO lnTotal
lnTotalInterest = lnTotalInterest +
laLoans[lnCount, 2]
ENDFOR
*/02 � End
ENDIF
Al comentar líneas que continúan, hay que comentar cada
línea física.
Incorrecto:
*/01 lcString =
"Esta cadena contiene mucho texto porque es un " ;
+ "ejemplo de una línea verdaderamente
larga "
Correcto:
*/01 lcString =
"Esta cadena contiene mucho texto porque es un " ;
*/01 + "ejemplo
de una línea verdaderamente larga "
Normas para interfaz de usuario (UI)
Cuando sea posible, la interfaz de usuario debe cumplir con
las directivas de Windows Standards descritas en el libro “Microsoft Windows User Experience “,
Microsoft Press, ISBN 0-7356-0566-1. Este libro se encuentra disponible en:
http://msdn.microsoft.com/library/en-us/dnwue/html/welcome.asp. Tenga en mente
todo el tiempo al usuario. Mientras más sencilla sea la funcionalidad para el
usuario, mejor será la aplicación. Esto puede significar que el código que está
detrás de esta funcionalidad es más complejo.
Formularios de entrada de datos
Todos los campos
aptos para entrada deben utilizar Select On Entry.
Los campos
numéricos deben ser formateados con comas y signos negativos cuando sea
necesario.
Si un campo es de
sólo lectura, establezca la propiedad TabStop en .F., Establezca la propiedad
ReadOnly a .T. o la propiedad Enabled a .F., según sea el caso. La propiedad
ReadOnly se utiliza cuando el campo nunca es modificable. La propiedad Enabled
se utiliza cuando el campo es modificable cuando se cumple una determinada
condición (es evaluada a .F.)
Utilice la barra
de estado para mostrar un mensaje al usuario que indique el propósito del
campo.
Muestre siempre
los valores predeterminados, en los casos en que se aplique.
Inhabilite
(Enabled = .F.) los objetos cuando sea necesario. Esto proporciona indicación
visual al usuario de que el objeto no puede ser modificado en ese momento.
Mensajes
No utilice WAIT
WINDOW para mostrar mensajes importantes al usuario. Es muy fácil que el
usuario no note el mensaje. En su lugar utilice MESSAGEBOX. Incluya siempre el
icono apropiado en el cuadro de mensaje (message box). Evite la utilización del
parámetro TIMEOUT, ya que el usuario puede perder información importante.
Utilice la barra
de estado para mostrar ayuda en línea para el objeto actual, ya sea en un
formulario o un menú.
Objetos de formulario
Text box. (cuadros
de texto) El cuadro de texto es el control más comúnmente utilizado. Puede
contener valores de caracteres, numéricos o fecha.
Check box.
(casilla de verificación) La casilla de verificación es un control sencillo que
está establecido en ON u OFF. Son utilizadas típicamente para indicar un estado
de Sí o No.
Command button.
(Botón de comando) El botón de comandos es utilizado para iniciar una acción.
Los botones más comúnmente utilizados son OK (Aceptar) y Cancel (Cancelar). Algunas
veces los botones de comandos son agrupados en los command group (grupos de
comandos). Intente evitar los grupos de comandos, los botones individuales son
más fáciles de mantener.
Option button.
(Botón de opción) En ocasiones se les llama radio button. Se utiliza para
indicar que el usuario puede seleccionar una opción de un grupo de opciones.
Los botones de opciones son frecuentemente agrupados en Option group (grupo de
opciones). Esto simplifica el código para el proceso de selección. Se recomienda
que los grupos de opciones se utilicen en lugar de los botones de opciones. Los
grupos de opciones deben ser preferiblemente ordenados verticalmente antes que
horizontalmente.
Drop-down list.
(Lista desplegable) Una lista desplegable permite al usuario hacer una
selección de una lista de varios objetos, como con un botón de opción. Sin
embargo, la lista desplegable requiere de menos espacio en pantalla.
Combo box. (Cuadro
combinado) Los cuadros combinados se identifican como un textbox en una flecha
hacia abajo. Se llama cuadro combinado, porque es una combinación de un cuadro
de texto y una lista desplegable. El usuario puede escribir un nuevo valor o
seleccionarlo de la lista.
List box. (Cuadro
de lista) Un cuadro de lista puede ser utilizado uno o varios objetos de una
lista.
Spinner. Un
control spinner es una especie de textbox con flechas hacia arriba y hacia
abajo. Es utilizado normalmente para datos numéricos. El número aumenta o
disminuye al hacer clic en las flechas o el usuario puede introducir un valor
específico.
Edit box. (Cuadro
de edición) Un cuadro de edición se comporta de forma parecida al textbox; pero
normalmente es utilizado para campos memo. Un editbox puede tener barras de
desplazamiento y deslizamiento de filas (word wrap)
