Ha adquirido una licencia de desarrollador de HotDocs, ha revisado los tutoriales y quizá incluso haya recibido formación en desarrollo. Es posible que haya llegado incluso a leer temas de interés en el archivo de ayuda de HotDocs o haya consultado la wiki de HotDocs. En cualquier caso, ya está listo para empezar a desarrollar aplicaciones de procesos HotDocs para su bufete de abogados o su empresa.
Su formación y sus lecturas le han enseñado que la funcionalidad principal de HotDocs gira en torno a los componentes o variables que usted crea. (Un componente es cualquier elemento que cree en el archivo de componentes asociado a su plantilla de documento [por ejemplo, cuadros de diálogo, variables, etc.]). Por lo tanto, es posible que se haya dado cuenta de que las convenciones de nomenclatura que utiliza para sus componentes son fundamentales para la funcionalidad y la facilidad de mantenimiento a largo plazo de sus aplicaciones HotDocs Process. A continuación, se incluyen tres reglas de nomenclatura que le ayudarán a iniciar su desarrollo con HotDocs.
Personajes prohibidos y un CASE exiliado
Los nombres de los componentes deben ser relativamente cortos, pero significativos. Un nombre de componente puede tener hasta 50 caracteres, incluyendo letras, números y algunos símbolos. Sin embargo, el primer carácter debe ser una letra. Cada nombre de componente debe ser único; incluso si los componentes son de diferentes tipos, sus nombres no pueden ser idénticos.
Los siguientes caracteres solo pueden utilizarse si hay un carácter distinto de un espacio inmediatamente antes o después de ellos; sin embargo, se se desaconseja encarecidamente, teniendo en cuenta los posibles cambios futuros en HotDocs:
No no utilizar los siguientes caracteres al nombrar los componentes:
Por último, dado que HotDocs utiliza MAYÚSCULAS para sus modelos de instrucciones y expresiones, se recomienda NO utilizar mayúsculas al nombrar los componentes. Por ejemplo, no se puede nombrar un componente «ADD ATTY TO MC», porque «ADD» es una palabra de instrucción reservada en HotDocs. Incluso si se utilizan mayúsculas para palabras en los nombres de los componentes que actualmente no son modelos de instrucciones o expresiones, nunca se sabe con certeza si HotDocs añadirá la palabra que se ha puesto en mayúsculas a su lista de palabras reservadas. Por lo tanto, es mejor utilizar «CamelCase», «Sentence case» o «minúsculas» que «MAYÚSCULAS». Lo sentimos.
Género > Especie/General > Específico
Una práctica que ayuda a organizar los componentes en el gestor de componentes, así como a mantener cosas las cosas similares es nombrar los componentes con palabras que empiecen por generales y luego se vuelvan más específicas. Por ejemplo, la raíz de la palabra en el nombre del componente podría ser una palabra clave principal para un grupo o un tema (por ejemplo, Cliente). Esta palabra clave suele ser la primera palabra del nombre del componente, pero, dependiendo del tipo de componente, puede que no sea así. Las palabras siguientes del nombre de la variable deben ser cada vez más específicas, describiendo primero un grupo secundario, si es necesario, y luego aspectos más específicos (por ejemplo,DescripciónLegalPropiedadInmueble). En general, la mejor práctica es evitar el uso de artículos y preposiciones en la medida de lo posible. Si puede elegir entre «NombreDelCliente» y «NombreCliente», utilice esta última.
Ejemplos
No desperdicies 50 caracteres, no te faltarán.
Aquí es donde me arriesgo a provocar una guerra de insultos. (Para aquellos que no estén familiarizados con el término, una guerra de insultos se desata en los foros de desarrollo de Internet cuando los defensores de convicciones opuestas y profundamente arraigadas sobre «su forma» de programar se menosprecian mutuamente en un hilo [por ejemplo, los productos de Microsoft frente a los de Apple]). Lo que sugiero aquí puede resultar poco práctico para aquellos desarrolladores que ya han automatizado muchas plantillas de documentos utilizando una convención de nomenclatura de componentes diferente, pero para aquellos que acaban de empezar, puede que valga la pena tenerlo en cuenta: utilicen «CamelCase» o «Title_Case_With_Underscores» al nombrar sus componentes, como he hecho en los ejemplos anteriores.
Tradicionalmente, muchos desarrolladores de plantillas han utilizado la notación húngara para indicar el tipo de componente (por ejemplo, TE para texto), y muchos han mantenido espacios en blanco («espacios») en los nombres de los componentes para facilitar la lectura. Los argumentos a favor del uso de la notación húngara han perdido relevancia desde HotDocs 5, ya que las versiones más recientes de HotDocs permiten a los desarrolladores de plantillas ver los tipos de componentes en el administrador de componentes como iconos o texto, y buscarlos y ordenarlos fácilmente. En cuanto a los espacios en blanco, omitir los espacios en los nombres de los componentes permite al desarrollador de plantillas disponer de muchos más espacios de los 50 asignados para rellenarlos con caracteres significativos que indiquen lo que hace un componente. Además, el uso de nombres de componentes sin espacios (por ejemplo, «CamelCase») es el estándar predeterminado para el desarrollo de modelos HotDocs (un tema que merece una futura entrada en el blog). Seguir esta convención permite a HotDocs leer el documento del modelo y convertir los nombres de variables «sin espacios» en indicaciones en la entrevista sin los errores que se pueden encontrar cuando se desactiva la convención de nomenclatura estricta.
Una última cosa a tener en cuenta es que, a medida que HotDocs sigue evolucionando y alineándose con otras tecnologías compatibles, puede surgir la necesidad de pedir a los usuarios que eliminen los espacios de los nombres de sus componentes. Si esto ocurriera, HotDocs proporcionaría una forma de convertir esos componentes con espacios, pero si no utilizas espacios desde el principio, estarás mucho más adelantado que el resto. Al final, la programación de HotDocs es un lenguaje de programación, por lo que la convención para nombrar componentes no solo debe ser adecuada para el desarrollo de plantillas de HotDocs, sino también para otros lenguajes de programación o scripting de la misma empresa.
¡Feliz desarrollo!
Nota de la Redacción: Este artículo se publicó originalmente en HotDocs.com. En junio de 2024, Mitratech adquirió la plataforma avanzada de automatización de documentos, HotDocs. El contenido ha sido actualizado desde entonces para incluir información alineada con nuestra oferta de productos, cambios en la regulación y cumplimiento.
