LotusScript es un lenguaje poderoso para programara aplicaciones Domino y Notes. Trabaja en el cliente de Notes, accediendo a las bases de datos en back-end y controlando el interfaz de usuario del cliente. Funciona en el servidor Domino, ejecutando agentes programados, o lanzados por eventos de documento. Y se puede lanzar desde un navegador de web cuando está embebido en un agente Domino.

El código LotusScript es bastante portable entre aplicaciones, de tal forma que puedes copiar piezas de codigo que escribiste previamente y usarlas como "inicio" en otro aplicación. El entorno de desarrollo de LotusScript ( que se encuentra en Domino Designer ) es tambien facil y conveniente, con chequeo de sintaxis en tiempo de diseño y depuración paso a paso. Por todas estas razones, LotusScript llegará a ser una herramienta estandar en tus habilidades en el desarrollo de aplicaciones.

Pero cuidado : el que sea conveniente y poderoso no significa que sea imposible el ser utilizado de mala manera. Puedes generar código de alta calidad y mantenible en LotusScript. Tambien puedes producir un enjambre de errores sucios y oscuros. Voy a darte algunas reglas fáciles de seguir las cuales te ayudarán a escribr LotusScript profesional. Mientras algunas de estas reglas te harán tomar unos cuantos segundos más el seguirlas inicialmente, te ahorrarán mucho tiempo ( y frustraciones ) a lo largo. Tus programas tendrán menos errores, y cuando haya un error, será más facil de localizar y corregir.

Consejo nº 1 : Usa Option Declare

Esta es la línea más importante de codigo que puedes escribir en una rutina de LotusScript. Colócala en la sección Options de cada uno de tus módulos de script. Option Declare fuerza a que declares todas las variables, ahorrándo el encontrarte muchos, muchos errores difíciles de encontrar. ( Los amigos de Iris deberían activar esta opción, en vez de desactivarla, por defecto).

Considera el siguiente trozo de código de script:

Const DEFAULT = "C" 
Dim Diskdrive As String 
Diskdrive = Inputbox$("Please enter drive letter.", "Drive?" ;, DEFAULT) 
' Use the default if user entered nothing. 
If Diskdrive = "" Then Diskdrve = DEFAULT 

Este código compila y ejecuta limpiamente cuando Option Declare no está presente. Desafortunadamente, el código tiene un error serio, ya que el nombre de la variable DiskDrive está mal escrito en la última línea. El código nunca hará lo que tú quieres que haga. Añadir Option Declare revelará el error tan pronto como queramos salvar el script.

Consejo nº 2 : Declara el Tipo Actual de Cada Variable

LotusScript te permite ejecutar "declaraciones perezosas" -- puedes declarar la existencia de la variable sin indicar su tipo. Cuando declaras una variable sin tipo, el tipo por defecto será Variant. El problema de esto es que las variables Variant pueden llegar a ser casi cualquier tipo de los existentes, permitiendo errores de no coincidencia de tipos.

Considera el siguiente ejemplo:

Dim LastName 
LastName = Doc.LName 
' many lines of intervening code . . . 
If LastName = "Clinton" Then Msgbox "Found record for Clinton."

Este trozo de código permite a la variable LastName tener por defecto el tipo Variant. Como resultado, el error codificado en la linea 2 compila y ejecuta correctamente. ( El programador en realidad quiso teclear LName(0) ya que los apellidos son cadenas en vez de arrays ). El error no se mostrará ; hasta que la última línea del programa se ejecute y causará un error de no coincidencia de tipos ( NT : Type mismatch ). Depurar este programa puede ser dificultoso porque el error real ( línea 2 ) está lejos de la línea que genera el mensaje de error ( la última línea ).

Para mejorar este ejemplo, debería ser reescrito como sigue:

Dim LastName As String 
LastName = Doc.LName 
' many lines of intervening code?. 
If LastName = "Clinton" Then Msgbox "Found record for Clinton."

El error todavía se encontrará en tiempo de ejecución pero el mensaje de error será provocado directamente por la línea que en realidad tiene el problema. Esto hace la depuración mucho más fácil. La línea 2 contiene una no coincidencia de tipos porque LastName está declarada con su tipo de dato real ( string ).

Consejo nº 3 : Usa constantes para cadenas y números

Es una práctica estandar en muchos lenguajes de programación el usar constantes en vez de cadenas y números tecleados directamente en el código. Muchos programas de LotusScript ignoran esta regla básica. Los programadores de LotusScript deberían estar en el vagón equivocado. La forma correcta de poner cualquier cadena o número dentro de un programa es crear una constante para ese valor, y así usar la constante en el cuerpo del código.

El usar constantes hace mucho más fácil el cambiar cadenas y números mientras el programa evoluciona. ( Y las cosas siempre cambian, incluso cuando la especificación indica que no lo harán ). Considera el siguiente ejemplo :

EnterAge: 
AgeString = Inputbox$("Please enter your age.", "Age?", "") 
AgeNumber = Cint(AgeString) 
If AgeNumber < 0 Or AgeNumber > 120 Then 
Msgbox "Are you sure you entered the right age?" 
Goto EnterAge 
End If 

Imagina este código lleno con miles de otras líneas y repetido en varios lugares. De repente, es un poco complicado el encontrar y cambiar las preguntas de los InputBox y las edades mínimas/máximas. El usar el "busca-y-reemplaza global" no es realmente una solución.

Aqui está el ejemplo reescrito usando constantes :

Const AGE_PROMPT = "Please enter your age." 
Const AGE_TITLE = "Age?" 
Const MIN_AGE = 0 
Const MAX_AGE = 120 
Const AGE_ERROR_MSG = "Are you sure you entered the right age?" 
EnterAge: 
AgeString = Inputbox$(AGE_PROMPT, AGE_TITLE, "") 
AgeNumber = Cint(AgeString) 
If AgeNumber < MIN_AGE Or AgeNumber > MAX_AGE Then 
   Msgbox AGE_ERROR_MSG 
   Goto EnterAge 
End If 

Escribiendo de esta forma, el codigo es mantenible y modificable. Un único cambio a la constante MAX_AGE ( o a cualquier de las otras constantes ) hará ese cambio en cualquier lugar donde la constante aparezca.

Consejo nº 4 : Usar nombres de campo "soft-coded"

En relación con el consejo anterior, uno de las peores trampas en LotusScript es usar nombres de campo como propiedades del documento. LotusScript hace simple el escribir a pelo nombres de campo, porque soporta los atributos extendidos de la clase NotesDocument. La documentación de LotusScript incluso describe esto como una característica, pero tú debes evitar esto como a una plaga.

Considera el siguiente ejemplo :

LastName = Doc.LName(0) 
FirstName = Doc.FName(0) 

Si estos nombres de campo ( LName y FName ) son repetidos docenas de veces a través del programa, entre muchos módulos de script, puedes necesitar mucho tiempo cambiando los nombres de estos campos si lo necesitas. Es muy fácil perder un campo. ( Option Declare no los controla, porque los campos son atributos de objeto, no declaraciones de datos ).

Una forma mejor de recuperar campos de un documento Domino es con el codigo siguiente :

Const FIRSTNAME_FIELD = "Fname" 
Const LASTNAME_FIELD = "Lname" 
LastName = Doc.GetItemValue(LASTNAME_FIELD)(0) 
FirstName = Doc.GetItemValue(FIRSTNAME_FIELD)(0)

Es simple el cambiar el nombre a un campo, da igual donde ocurra en la aplicación, haciendo un cambio único a su definición de nombre constante. De una forma similar, deberás escribir las operaciones de escritura a campos, como se muestra en este ejemplo :

Const FIRSTNAME_FIELD = "Fname" 
Const LASTNAME_FIELD = "Lname" 
Const LASTNAME_PROMPT = "Please enter the last name." 
' Constants for FIRSTNAME_PROMPT, LASTNAME_TITLE, FIRSTNAME_TITLE 
' go here. 
LastName = Inputbox$(LASTNAME_PROMPT, LASTNAME_TITLE, "") 
FirstName = Inputbox$(FIRSTNAME_PROMPT, FIRSTNAME_TITLE, "") 
Set Item = Doc.ReplaceItemValue(LASTNAME_FIELD, LastName) 
Set Item = Doc.ReplaceItemValue(FIRSTNAME_FIELD, FirstName)

De nuevo, un cambio en una línea a una definición de constante cambiará el nombre del campo a través de toda la aplicación.

Consejo nº 5 : Usar comentarios copiosos y con contenido

Tómate tu tiempo para escribir comentarios que ayudarán al próximo programador. La siguiente persona que trabaje en el código puede ser un amigo tuyo o, muy posiblemente, tu mismo un mes más tarde. ( Es fascinante lo que puedes olvidar sobre tu propio código si éste no tiene comentarios. ) Pon un bloque de comentarios al inicio de cada módulo. ( Por " módulo", simplemente quiero decir cualquier porción de script que visualemente tiene sentido por sí misma, incluyendo subrutinas, funciones, rutinas de bibliotecas compartidas, eventos del formulario, acciones, etc. ) El bloque de comentario debería contener las siguientes secciones : SUMARIO, NOTAS ESPECIALES, y HISTORIA. Aquí tienes un ejemplo el cual eres libre de copiar :

%REM 
SUMARIO
Encuentra respuestas que han perdido datos en alguno de los campos. Esto es el 
resultado de que algunos nombres de campos fueron cambiados por error, y luego 
vueltos a sus nombres originales de nuevo. Toma los datos en los nombres de los 
campos correctos. Tambien encuentra al padre ( formulario principal ) de cada 
una de las respuestas y se asegura que sus campos son correctos tambien. 
NOTAS ESPECIALES 
Este código asume que cada respuesta está correctamente 
vinculada ( un hijo de ) a su documento principal padre. 
HISTORIA 
12/7/99, Chuck Connell, creado desde otro agente como plantilla. 
12/8/99, Chuck Connell, Se hace más eficiente salvando los documentos sólo 
una vez, y solo si son cambiados en realidad. 
12/8/99, Chuck Connell, Manejador de errores añadido. 
12/14/99, Chuck Connell, Modificado de forma que se ejecute sobre 
los documentos seleccionados ( desde una vista ) en vez  
de sobre todos los documentos de una vista.
%END REM 

La sección SUMARIO explica porqué el módulo fue escrito y cual es su mecanismo básico. Esta sección ayuda a los miembros de un nuevo equipo a entenderse rápidamente sobre la estructura del programa.

La sección de NOTAS ESPECIALES contiene información sobre aspectos que pueden dar problemas al siguiente programador ( o a ti ). Por ejemplo, si el módulo puede ser ejecutado solo con alguien de acceso Gerente, se indicaría aquí. O, si el código tiene problemas conocidos, por ejemplo. Si no hay información crea la sección y déjala en blanco para uso futuro.

La sección HISTORIA cuenta quien escribió el código en primer lugar y brevemente detalla cada cambio realizado. Es algo util cuando tenemos que hablar con ingenieros de versiones previas del módulo. Y es muy útil si estamos siguiendo la pista hacia atrás de errores misteriorosos más tarde en el ciclo de desarrollo. ( Un pequeño cambio puede haber causado un problema inintencionadamente ).

Siempre añade una línea por cada cambio que hagas, incluso si éste es pequeño. Finalmente, usa comentarios que aclaren las cosas a través del cuerpo del código. Los Comentarios explicativos seguirán los consejos que se acaban de describir. Ellos le dirán al lector porqué una sección de código está ahí, cual es su propósito, y cómo se relaciona con el resto del código.

Implementar estos consejos de codificación puede hacerte que te tomes más tiempo cuando comienzes a usarlos. Rápidamente observarás el ahorro por el tiempo que has invertido, sin embargo. Esto es verdad especialmente al final de un proyecto, cuando los desarrollos son más duros y cada minuto de depuración es un minuto demasiado largo. Los métodos que he presentado reducirán el número de errores que tengas, y hará más facil encontrar y arreglar errores que puedan existir.