Identificadores
Los identificadores son una pieza clave en el desarrollo de aplicaciones Velneo. Es el elemento que más vamos a utilizar en nuestros desarrollos para hacer referencia a cada objeto, subobjeto o control.
El tamaño del identificador es muy importante no solo por su legibilidad sino porque es el código o referencia que se utilizará en el resto de puntos de la aplicación para ejecutar el objeto, subobjeto o hacer referencia a un control. Por lo tanto aquí el tamaño sí importa ya que si utilizamos identificadores muy largos el tamaño de nuestros proyectos pueden incrementarse notablemente.
Hay que tener en cuenta que un simple campo puede ser usado cientos de veces. Si su identificador tiene un tamaño de 50 caracteres estamos hablando de una ocupación de varios miles de bytes. Para reducir el tamaño de los identificadores podemos usar abreviaturas que nos aportarán 2 grandes beneficios:
- 1.Reducción del tamaño que nos beneficiará en el tamaño de los proyectos.
- 2.En el árbol de propiedades poder ver completo el identificador del objeto usado.
Evidentemente, las abreviaturas también tienen una desventaja y es que debemos de interpretar la abreviatura para conocer la palabra a la que sustituye. Para facilitar esta labor es conveniente utilizar un diccionario de abreviaturas.
Además, el diccionario nos aporta otra gran ventaja, como es el conseguir que todos los programadores escribamos igual los identificadores. Precisamente, cuando no se usa un diccionario de términos o abreviaturas es habitual que cada programador escriba la misma palabra de una forma distinta, por ejemplo: FACTURAS, FACTURA, FACT, FRA, etc.
En definitiva, un equipo de desarrollo debe contar con un diccionario de abreviaturas que puede estar almacenado en una aplicación, una hoja de cálculo o un documento de texto, es muy importante que cuente con un sistema de búsqueda ágil. Lo fundamental para el equipo es que exista, que se utilice y que se mantenga actualizado. Es recomendable que al lado de la abreviatura se indique todos los términos que la utilizarán.
En el diccionario se puede aplicar por convenio el uso de palabras en un solo idioma, todo en Español, todo en Inglés o también ser menos estricto y utilizar palabras en su mayoría en tu idioma nativo permitiendo alguna excepción cuando aporte legibilidad y reducción de tamaño.
3 es un número que nos permite una gran combinación de caracteres alfanuméricos con un tamaño muy reducido.
Un problema que nos podemos encontrar con el uso de abreviaturas de 3 caracteres es la coincidencia de varios términos, por ejemplo IMP se puede usar para los términos “importe”, “importar” y también “imprimir”. En muchos casos el contexto facilita la interpretación del significado, es decir si la abreviatura se escribiese sola, por ejemplo un campo IMP si está en una tabla de líneas de detalle es fácil interpretarlo como importe antes que importación o impresión. Sin embargo, en muchos casos los identificadores son compuestos de varias abreviaturas, de esta forma IMP_TOT es fácil interpretarlo como importe total, SND_IMP como senda de importación. Incluso para evitar estas coincidencias se pueden usar alteraciones o abreviaturas estándar del mercado, por ejemplo PRT (print) para imprimir. De esta forma si vemos VTA_FAC_PRT lo interpretaremos como impresión de la factura de venta.
Es cierto que con 4 caracteres sería más fácil evitar algunas coincidencias como las comentadas anteriormente, sin embargo la longitud de los campos se dispararía, incluso algunas abreviaturas serían más complejas de elaborar ya que cuantos más caracteres más decisiones hay que utilizar para la combinación de consonantes y vocales. En el ejemplo anterior VNTA_FACT_PRNT sería el mismo identificador de impresión de facturas de venta con abreviaturas de 4 caracteres, como podemos apreciar hay palabras difíciles de abreviar como venta que se podría haber abreviado como VENT, VETA, VNTA o VTAS no siendo ninguna de ellas demasiado satisfactoria.
Recordar 3 abreviaturas de 3 caracteres es más sencillo que de 4 ó más. Además, a medida que vamos desarrollando las aplicaciones nos daremos cuenta de que se van construyendo objetos cuyo identificador es cada vez más y más largo para poder expresar de forma concreta y única la funcionalidad del mismo. Por ejemplo para el formulario de detalle de una línea de pedido de venta podríamos encontrarnos con estas posibilidades:
Tipo | Identificador |
Sin abreviar | VENTA_PEDIDO_LINEA_DETALLE |
Abreviatura de 4 | VNTA_PEDI_LINE_DETA |
Abreviatura de 3 | VTA_PED_LIN_DET |
Ahora imagínate cómo se llamaría un tubo de ficha que genera una línea de factura de venta a partir de una línea de pedido.
Tipo | Identificador |
Sin abreviar | VENTA_PEDIDO_LINEA_TO_VENTA_FACTURA_LINEA |
Abreviatura de 4 | VNTA_PEDI_LINE_DETA_TO_VNTA_FACT_LINE |
Abreviatura de 3 | VTA_PED_LIN_DET_TO_VTA_FAC_LIN |
Aplica cada uno de los tipos a todos los identificadores de tu aplicación y podrás comprobar como te encontraras con objetos cuyos identificadores son extra largos. Sin duda las abreviaturas son un magnífico recurso para reducir el tamaño y facilitar la legibilidad.
Por último indicar que cuando se establece un máximo de 3 caracteres en las abreviaturas no implica que todas deban tener ese tamaño, también se admiten abreviaturas de menor tamaño como por ejemplo “A”, “OK”.
Estas palabras no deben ser usadas cuando no aportan valor semántico significativo, algo que ocurre en la mayoría de los casos.
Velneo no permite el uso de espacios en blanco ni caracteres especiales en los identificadores, por este motivo esos caracteres son sustituidos de forma automática por el guión bajo “_”. Para facilitar la legibilidad de los identificadores usaremos el separador entre cada abreviatura.
Tipo | Identificador |
Sin separador, difícil de leer | VTAPEDLINDETTOVTAFACLIN |
Con separador, más fácil de leer | VTA_PED_LIN_DET_TO_VTA_FAC_LIN |
Hacerlo tiene 2 desventajas. La primera es aumentar el tamaño del identificador y la segunda es que estarás aplicando una información redundante ya que el tipo de objeto está representado por su icono y en la ventana de propiedad se indica el nombre del tipo de objeto.
Por lo tanto debemos evitar usar identificadores como ACC_VTA_FAC_G_MEN ya que como vemos además de ser más largo la información que aporta es redundante, e incluso lo más probable es que allí donde se use tan solo podríamos utilizar objetos de este tipo.
Una de las características de los objetos en Velneo es que disponen de origen y destino (ninguno, ficha o lista), por este motivo es muy importante poder identificar el origen de cada objeto sin necesidad de revisar en su propiedad el origen.
Por este motivo es importante que los identificadores de las tablas sean a la vez descriptivos y lo más cortos posible.
Aplicando el diccionario conseguimos tablas con identificadores de 1 abreviatura y otras 2 y hasta 3 abreviaturas de 3 caracteres. En general no conviene sobrepasar las 3 abreviaturas ya que acabaríamos teniendo identificadores demasiado largos.
Es habitual que haya tablas relacionadas bien por su funcionalidad o porque pertenecen al mismo submódulo, como por ejemplo "COM" para compras y "VTA" para ventas. En estos casos es conveniente que el dato “común” o agrupador sea el de más peso y se use como prefijo, en nuestro ejemplo es correcto poner VTA_PED para pedido de venta en lugar de PED_VTA. De esta forma conseguimos que alfabéticamente las tablas del mismo submódulo estén juntas. Si no aplicamos este criterio el orden alfabético producirá una organización más caótica.
Existen objetos en los que es muy importante tanto su origen como su destino. Un caso claro son los tubos de ficha y lista. En estos objetos es conveniente que el identificador incluya ambas tablas.
En el ejemplo podemos apreciar como cuando la tabla de origen y destino son diferentes se separan con la abreviatura TO. Es cierto que está en inglés, pero es una abreviatura corta y fácil de leer e interpretar.
Podemos apreciar que cuando la tabla de origen y destino es la misma se está aplicando en este caso el sufijo _DUP para indicar que el objeto creará un duplicado del registro de origen.
En el último ejemplo el sufijo es _MEM, esto se utiliza para indicar que se generarán los registros de origen en la misma tabla de destino pero en memoria, en lugar de repetir el identificador completo de la tabla PRS_OBJ_W_MEM se utiliza solo el sufijo diferencial. Estos casos son bastante excepcionales por lo que si se aplica la norma aunque el identificador sería mucho más largo PRS_OBJ_W_TO_PRS_OBJ_W_MEM sigue siendo igual de válido.
El editor no permite que dos tablas tengan el mismo identificador en el mismo proyecto, pero sí es posible crear dos tablas con el mismo identificador en distintos proyectos. Cuando se trabaja con múltiples soluciones o múltiples proyectos heredados o incluso cuando se trabaja sobre un núcleo común a todas las aplicaciones hay que tener especial cuidado en conseguir que no se repita el identificador de una tabla.
El problema se produce cuando al instanciar ambos proyectos se realiza sobre la misma carpeta del disco produciéndose un conflicto al solo existir una tabla que tiene dos definiciones de estructura diferentes en los proyectos.
Para evitar esta duplicidad de identificadores es conveniente usar un sufijo diferenciador que permita poner identificadores a las tablas sin riesgo de caer en la duplicidad. Conviene que esos sufijos tampoco se repitan. Se puede utilizar el criterio de un sufijo diferente por aplicación, módulo, etc.
Como el número de aplicaciones o módulos no suele ser muy alto, se pueden utilizar sufijos con una sola letra, por ejemplo: "_G" para gestión, "_C" para contabilidad, "_M" para maestros generales, "_W" para configuración, etc. En caso que el nº de aplicaciones o módulos sea muy grande se pueden colocar 2 ó más letras.
Para mantener un criterio único, se aplicará el mismo criterio de las tablas a las tablas estáticas y también a las variables globales que tengan una relación directa con un módulo.
Aunque las tablas tengan un sufijo y cuando añadimos campos a una tabla se crean con el mismo identificador de la tabla tanto el campo como el índice correspondiente. Por mejorar la legibilidad de los subobjetos de la tabla: campos, índices y actualizaciones, quitaremos del identificador el sufijo correspondiente.
Por ejemplo, si la tabla de artículos tiene como identificador "ART_M", las diferentes tablas de líneas de detalle de compras y ventas tendrán un puntero al artículo cuyo campo, índice o actualización tendrá como identificador "ART" en lugar de "ART_M".
Por regla general coincidirá el identificador del campo con el de la tabla o tabla estática apuntada. Es decir, el campo puntero al artículo se identificará como "ART" ya que su tabla maestra se identifica como "ART_M".
Sin embargo, se pueden dar circunstancias que no permitan usar el identificador exacto de la tabla:
Si en una misma tabla existen varios punteros a la misma tabla maestra, es lógico que el identificador sea más explícito, y por lo tanto diferente al de la tabla maestra. Por ejemplo si una entidad puede tener forma de pago para cobros y forma de pago para pagos, si la tabla de formas de pago se identifica como "FPG_M", los campos podrían identificarse como "FPG_COB" y "FPG_PAG" respectivamente.
En ocasiones hay tablas que contienen múltiples tipos de registros, por ejemplo el caso de la tabla de entidades o contactos que puede servir para almacenar diferentes tipos de registros como clientes, proveedores, comerciales, etc. En estos caso se podrían utilizar los siguientes identificadores en la tabla de factura de venta:
Tipo | Identificador | Comentario |
ENT | Cliente | Desaconsejable si en la tabla pueden existir otros campos punteros a la entidad como el comercial. |
ENT_CLT | Cliente | Es válido ya que permite que el comercial tenga como identificador ENT_CMR. |
CLT | Cliente | Este es el identificador más corto, pero además es el más explícito ya que indica el uso del dato y no el origen de la tabla. Para campos de uso masivo como el de clientes, proveedores, etc. Este identificador puede ser el más conveniente. |
En cualquier caso debe existir un consenso en el equipo de cuál de los 2 últimos utilizar.
No te preocupes por los identificadores repetidos en el proyecto
Es cierto que si miramos los identificadores de la carpeta de una tabla encontraremos muchas repeticiones. Sin embargo, esto es algo permitido por el editor de Velneo ya que el identificador “completo” de un objeto viene dado por: el proyecto + el tipo de objeto + el identificador.
De esta forma para un mismo proyecto podemos tener objetos con el mismo identificador siempre que sean de diferente tipo. Esto nos permite utilizar el mismo criterio para todo los objetos sin necesidad de recurrir a un prefijo o sufijo que lo indique el tipo de objeto.
Última actualización 9mo ago