Ha adquirido una licencia de desarrollador de HotDocs, ha revisado los tutoriales e incluso puede que haya recibido formación sobre desarrollo. Es posible que haya llegado a leer temas de interés en el archivo de ayuda de HotDocs, o que haya ojeado la Wiki de HotDocs. En cualquier caso, ya estás listo para empezar a desarrollar aplicaciones de procesos HotDocs para tu bufete o 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 cosa que cree en el archivo de componentes y que esté asociado a su plantilla de documento [por ejemplo, cuadros de diálogo, variables, etc.]). Por lo tanto, es posible que se le haya ocurrido que las convenciones de nomenclatura que utilice para sus componentes son fundamentales para la funcionalidad y utilidad a largo plazo de sus aplicaciones HotDocs Process. He aquí tres reglas de nomenclatura que le ayudarán a comenzar el desarrollo de HotDocs.
Personajes prohibidos y una CASE exiliada
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: aunque los componentes sean de distinto tipo, sus nombres no pueden ser idénticos.
Los siguientes caracteres sólo pueden utilizarse si hay un carácter distinto de un espacio inmediatamente antes o después de ellos; sin embargo, se desaconseja encarecidamente su uso se desaconseja encarecidamenteteniendo en cuenta posibles cambios futuros en HotDocs:
Usted no puede utilizar los siguientes caracteres al nombrar sus componentes:
Por último, dado que HotDocs utiliza MAYÚSCULAS para sus modelos de instrucciones y expresiones, es una buena práctica NO utilizar mayúsculas al nombrar los componentes. Por ejemplo, no puede nombrar un componente "ADD ATTY TO MC", porque "ADD" es una palabra de instrucción reservada en HotDocs. Incluso si utiliza mayúsculas en los nombres de los componentes que no son actualmente modelos de instrucciones o expresiones, nunca sabrá con seguridad si HotDocs añadirá o no la palabra que ha puesto en mayúsculas a su lista de palabras reservadas. Así que es mejor "CamelCase", "Sentence case" o "lowercase" que "UPPERCASE" y lo siento.
Género > Especie/General > Específico
Una práctica que ayuda a organizar los componentes en el gestor de componentes, así como a mantener en general como cosas con como es nombrar los componentes con palabras que empiecen siendo generales y luego se vuelvan más específicas. Por ejemplo, la palabra raíz en el nombre del componente podría ser una palabra clave primaria para un grupo o un tema (por ejemplo, ClienteCliente). Esta palabra clave suele ser la primera palabra del nombre del componente pero, dependiendo del tipo de componente, puede no serlo. 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 después aspectos más concretos (por ejemplo, ClienteRealPropertyLegalDescription). En general, la mejor práctica consiste en evitar el uso de artículos y preposiciones en la medida de lo posible. Si puede elegir entre "NombreDelCliente" y "NombreDelCliente", utilice este último.
Ejemplos
No desperdicies 50 caracteres
Aquí es donde me arriesgo a provocar una guerra de llamas. (Para los que no estén familiarizados con el término, una guerra de llamas se desata en los foros de desarrollo de Internet cuando los defensores de convicciones opuestas y profundamente arraigadas sobre "su manera" de codificar se menosprecian unos a otros en un hilo [por ejemplo, productos de Microsoft frente a productos de Apple]). Lo que sugiero aquí puede ser 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 valer la pena considerarlo: Utilice "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 los espacios en blanco ("espacios") en los nombres de los componentes para facilitar la lectura. Los argumentos para emplear la notación húngara han perdido relevancia desde HotDocs 5, ya que las versiones más recientes de HotDocs han permitido a los desarrolladores de plantillas ver los tipos de componentes en el gestor de componentes como iconos o texto, y buscar y ordenar fácilmente entre ellos. En cuanto a los espacios en blanco, al omitir los espacios en los nombres de los componentes, el desarrollador de plantillas dispone de muchos más espacios de los 50 asignados para rellenar 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 por defecto para el desarrollo de modelos HotDocs (un tema digno de una futura entrada en el blog). Seguir esta convención permite a HotDocs leer el documento Modelo y convertir los nombres de variables "Sin espacios" en indicaciones en la entrevista sin los errores que puede encontrar con la convención de nomenclatura estricta desactivada.
Un último aspecto a tener en cuenta es que, a medida que HotDocs siga evolucionando y alineándose con otras tecnologías compatibles, puede surgir la necesidad de exigir 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 usas espacios en primer lugar, estás mucho más adelantado que el rebaño. Al final, el scripting de HotDocs es un lenguaje de programación, por lo que la convención para nombrar componentes debería ser no sólo apropiada para el desarrollo de plantillas HotDocs, sino también de la misma compañía con otros lenguajes de programación o scripting.
¡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.
