Nomenclatura y estandares

[[Al González]]

¡Hola a todos!

Este tema me interesa porque soy un partidario de la estandarización de nomenclaturas. Personalmente he comprobado cómo el llevar un estándar reduce significativamente los tiempos de desarrollo, depuración, mantenimiento y modificación del software.

En lo referente a bases de datos, de entrada les comento que no uso el guión bajo ("_") en el nombre de sus elementos. No lo utilizo para los nombres de tablas, campos y otros objetos por tres razones:

1. Es difícil de teclear. Esa fracción de segundo que dedicamos a sostener el Shift mientras presionamos (y recordamos su posición según la configuración de teclado) el guión bajo termina siendo un detalle incómodo para el programador. Y todos sabemos que en desarrollo de software entre menos detalles incómodos tengamos mejor y más rápido salen las cosas. Somos muy dados a optimizar la memoria y tiempo consumidos por las rutinas de código, pues lo mismo debemos aplicar a las rutinas laborales ¿no creen? .

2. Es poco estético y muchas veces innecesario. Cuando se permite el uso de mayúsculas y minúsculas (y no hay conflictos técnicos importantes al respecto), se puede prescindir del guión bajo empleando altas y bajas a la manera de NomenclaturasBuenas, PrecioMenudeo, PrecioMayoreo.

3. Se hace invisible en hipervínculos y textos subrayados. Si por ejemplo, en la documentación de la base de datos tenemos una sección o hipervínculo con el título subrayado "DEPENDENCIAS DE LA TABLA AREAS_VIGENTES" ("DEPENDENCIAS DE LA TABLA AREAS_VIGENTES"), un programador de nuevo ingreso podría pensar que se trata de las dependencias vigentes de la tabla AREAS en lugar de las dependencias de la tabla AREAS_VIGENTES. Ese tipo de confusiones entorpecen el trabajo de los desarrolladores.

Por otra parte, creo cada tabla con un nombre en plural cuando ésta podrá contener más de un registro, como sucede casi siempre (por ejemplo, EMPLEADOS, AREASVIGENTES), y en singular solamente cuando es una tabla de un sólo registro (por ejemplo, CONFIGURACION, DATOSEMPRESA).

Con respecto al campo de llave primaria o de identidad, éste lo nombro simplemente "ID" (el uso del término ID es ya un estándar fuertemente aplicado y aceptado por la comunidad mundial de desarrolladores), y para los campos que se relacionan con el ID de otra tabla utilizo el nombre completo de esa otra tabla con el prefijo "ID". Por ejemplo, si tenemos dos tablas, "VENTAS" Y "VENTASPARTIDAS", en una relación maestro-detalle, respectivamente. Los campos llave de dichas tablas son:

VENTAS.ID (identificador de registro, llave primaria)
VENTASPARTIDAS.ID (identificador de registro, llave primaria)
VENTASPARTIDAS.IDVENTAS (relacionado con VENTAS.ID, llave externa).

Nótese también que el nombre de la tabla detalle, "VENTASPARTIDAS", lleva como prefijo el nombre de la tabla maestra ("VENTAS").

Hay quienes no utilizan nunca ID como nombre completo de campo, sino que siempre le anexan el nombre de una tabla ("VENTAS.IDVENTAS", por ejemplo). Encuentro tres desventajas en esa forma de hacerlo:

1. Si el nombre de la tabla cambiara, tendríamos que cambiar también el nombre del campo.

2. Es un pleonasmo. Como decir «cayó algo del cielo de arriba». ¡Cervantes se levantaría de su tumba! Ya sabemos que el cielo está arriba. En programación debe uno cuidar que no se caiga ni en la escasez ni en la abundancia de texto, ya que los dos extremos le exigen una mayor cantidad de tiempo-neurona al cerebro.

3. Se pierde la distinción entre los nombres de campos de llave primaria y los de llave externa/secundaria. Como lo propongo ("VENTAS.ID"), al comenzar a leer la sentencia SQL «Select IDVentas...» podemos intuir que se trata de una consulta sobre la tabla VENTASPARTIDAS antes de llegar al From. En cambio, si el campo fuera "VENTAS.IDVENTAS", forzosamente tendríamos que leer algo más de la sentencia Select para estar seguros de si es una consulta sobre la tabla VENTASPARTIDAS o sobre la tabla VENTAS.

Allende, hay quienes, para campos relacionados, utilizan el nombre de la otra tabla con el par de letras "ID" como sufijo en lugar de prefijo. Ejemplo: "VENTAS.CLIENTESID". El problema de ese estilo es que se pierde uniformidad y eficacia cuando listamos o buscamos los campos de una tabla por orden alfabético. Por ejemplo, quizá estamos tecleando instrucciones de la aplicación o SQL en un editor que soporta auto completado de código (code insight), y enseguida queremos escribir el nombre de un campo relacionado pero no recordamos como se llama la otra tabla. De la manera que lo propongo ("ID" como prefijo), sólo tenemos que teclear ID y estaremos a un paso de seleccionar el campo cuyo nombre completo no recordábamos. En cambio, si se utiliza ID como sufijo, tenemos que examinar la lista de campos completa para localizar el nombre que buscamos.

Este esquema de nomenclaturas que propongo y utilizo ha resultado de lo más eficiente e inteligible para los desarrolladores que trabajamos en diversos proyectos de mi empresa y de algunos clientes. La esencia del mismo es ser prácticos y sencillos, no complicarnos con nomenclaturas bárbaras sostenidas más en fundamentalismos sico-informáticos que en su facilidad de uso y resultados de la vida real.

Generalmente el programador común no acepta con facilidad cambiar de estilo (alguna vez yo fui uno de tantos obstinados, viviendo en mi pequeño y perfecto mundo). No obstante, la tolerancia y la flexibilidad son un signo de madurez muy valorado por las empresas, y dos cualidades imprescindibles para lograr lo que uno quiere en la vida.

Propongo mi esquema de nomenclaturas para bases de datos, como cimiento de un estándar al que podamos contribuir todos.

Espero esto sea de utilidad, seguimos en contacto.

Ahora si, a dormir se ha dicho. ¡Hasta mañana!

Al González.

[Mauro.NET]

En el caso de las tablas relacionadas que conforman un maestro detalle directo, como por ejemplo en el caso de FACTURAS, (cabecera e items),
a las tablas las llamo

Factura_021
Item_Factura_022

Lo del sufijo numerico y guión bajo reconozco que es pésimo. En una base de datos nos encontramos con muchas relaciones de este tipo, y hasta ahora lo unico que encuentro rapidamente en mi base son los Items por que estan todos agrupados por el prefijo "Item_", si este modelo fuera comodo para alguno, usaria el prefijo "Cab_" o algo asi para identificar perfectamente las cabeceras.

Pienso que hay que organizar las cosas como dice la teoria general de los sistemas: "De lo general a lo particular".

Entonces a estas tablas las llamaria

FacturaCab
FacturaItem

solo estoy tirando algunas ideas, pero la fruta está muy verde todavia...
espero que ustedes aporten algo a esta iniciativa.

[roman]

¡Caramba Al! Has escrito toda una novela

En mucho estoy de acuerdo contigo. Yo solía llamar mis llaves primarias anteponiendo el nombre de la tabla hasta que, como dices, me percaté del pleonasmo.

Creo que hay que observar que lo de llamar ID a la llave primaria es más que una convención de nomenclatura; es una convención de que todas las tablas tendrán una llave primaria formada por un sólo campo.

Para el resto de los campos pues trato de usar nombres que me digan algo. En una tabla de productos, descripcion me parece un nombre adecuado para la descripción del producto. Es decir, ¿para qué usar nombres raros?.

Para llaves foráneas, lamento no concordar con Al (eso de por si acaso usamos un editor que soporte autocompletado me parece una razón un poco artificial ).

La relación en mi tabla productos al cliente se llama cliente_id. Cuando hacemos joins:

Código SQL [-]
productos.cliente_id = clientes.id

me parece muy natural que vayan en el mismo orden. No omito el guión bajo porque con la mano izquierda oprimo SHIFT y con la derecha el guión y me sorprende que Al, que sabe mecanografía, esté en contra de su uso

// Saludos

[ContraVeneno]

Saludos a todos

Vaya que Al se avento todo un cápítulo sobre nomenclaturas, pero en general, estoy totalmente de acuerdo con lo que dice. De igual forma estoy en contra del uso del guion, prefiero usar las mayúsculas y minúsculas como bien menciona Al en sus ejemplos. Supongo que leímos el mismo libro o algo similar porque utilizamos los mismos estándares. Saludos Al

Habría que mencionar, que cada programador tiene su propio estilo con respecto a las nomenclaturas y cada quien esta en su derecho de utilizar el método que más le guste. Pero cuando trabajas en grupo, el hecho de cada quien utilize su propio estilo se convierte en un problema; lo más conveniente es que el grupo defina sus políticas y estándares para facilitar el trabajo de todos y que los integrantes del grupo se ajusten a estos estándares y políticas.

Otro punto sería, el utilizar prefijos que sean muy claros para todos, de lo contrario sería mejor utilizar la palabra completa. De cualquier manera todos sabemos mecanografía y podemos escribir muuuy rápido (ya en serio, aprender mecanografía es muy sencillo y te trae muchos beneficios. Es altamente recomendable aprender mecanografía)


Saludos

P.D. Es la primera vez que veo que colocan prefijos o subfijos numéricos en una nomeclatura, no entiendo cual es la función de hacer esto y no veo ninguna razón para hacerlo.

[roman]

Empezado por ContraVeneno

De igual forma estoy en contra del uso del guion, prefiero usar las mayúsculas y minúsculas como bien menciona Al en sus ejemplos.

¿Y por qué es más difícil oprimir SHIFT para el guión que para una mayúscula?

// Saludos

[ContraVeneno]

Nunca dije que fuera más dificil o más fácil. Y si, creo que es lo mismo utilizar el shift para poner una mayúscula que para poner el guíon (o subrayado).

Pero mi muy particular y muy personal punto de vista, sigue siendo el mismo: yo no utilizo el guión, me parece poco estético y siento que escribo un caracter extra (multiplicado por 10 campos y multiplicado por 100+ tablas, son demasiados caracteres extra); prefiero escribir "TirePosition" que escribir "tire_position".

Pero como dije antes, este es mi muy particular y muy pesonal estilo, cada quien es libre de utilizar el estilo que más le guste; cuando trabajas en grupo, el estilo lo definirá el lider del grupo o el grupo en conjunto.

--Saludos

[[Al González]]

¡Hola a todos!

Gracias por sus comentarios Román, Eärandir.

Casi no suelo hacer aclaraciones sobre algo que ya de por sí es claro, pero esta vez haré una excepción que considero prudente para la correcta fluidez del tema.

Empezado por roman

...No omito el guión bajo porque con la mano izquierda oprimo SHIFT y con la derecha el guión y me sorprende que Al, que sabe mecanografía, esté en contra de su uso ...

En parte por ello escribí «difícil» en letra cursiva. Trato de ponerme en los zapatos de todos los programadores que integran un grupo de trabajo. Además expuse claramente otras dos razones por las cuales prefiero abstenerme de utilizar el guión bajo.

Empezado por ContraVeneno

...Supongo que leímos el mismo libro o algo similar porque utilizamos los mismos estándares. Saludos Al ...

Hombre, prefiero no decir cuántos libros de informática he leído . Quizá sea que un servidor también vivió en Torreón . Y ya de paso te pido una disculpa por lo que pensaba de tu ciudad hace ocho años .


Seguimos en contacto.

¡Un abrazo a todos!

Al González.

[Mauro.NET]

Hola chicos, me sorprende la repercusión que tuvo este hilo hacia ustedes, probablemente tuvieron la misma inquietud alguna vez. Gracias por sus aportes.

Con respecto a lo del uso del guion bajo, por experiencia personal, yo utilizo teclado ingles por comodidad, pero esta tecla no está al lado del shift, sino arriba de todo donde estan todos los teclas de caracteres especiales &^&*()_=-+ etc.
Pero la ventaja de este tipo de teclados es mucho mas relajado a la hora de programar en delphi, ya que no tengo tengo que presionar tantas veces la tecla shift para los simbolos comunes en delphi, como por ejemplo = ; ' [ ] / como otros teclados.

Con respecto a la lectura de codigo SQL, no deberiamos dejar de lado si las palabras reservadas del SQL es convenientes mostrarlas en mayusculas o en minusculas, yo normalmente opto por la primera opcion y trato de orgainizar el codigo para que quede amigable posible para el programador.

[ContraVeneno]

Al, no te apures, al ciudad si ha cambiado en los últimos 8 años, supongo que te sorprendería... eso sí, la tierra y la falta de agua seguirán, no por nada es zona desértica y las tormentas de arena (polvo) seguirán y seguirán.

Continuando con el tema, creo que hay puntos que ya son de obligación para todos los programadores; sobre los cuales ya se han escrito muchos manuales, tips, etc:
1.- Palabras reservadas en SQL en mayúsculas (hay quien incluso utiliza este método para todas las palabras reservadas del lenguaje que utilizan)
2.- Indexación o sangría para que el código se lea mejor.
3.- (el más olvidado de todos y que podría resolver muchos problemas) Colocar comentarios en el código

Por cierto, sigo sin entender porque o para que colocar subfijos o prefijos numéricos en la nomenclatura

Saludos!

[roman]

Yo en cambio nunca he entendido porqué la insistencia en usar mayúsculas para las palabras reservadas... se ve taaan feo

¿O es que en algún momento podría pensar que 'select', 'join', 'delete' son nombres de campos? Quizá al comenzar a trabajar con sql se preste a confusión pero después es igual que en un escrito cualquiera que esté plagado de mayúsculas.

Eso sí, la indentación y apropiados cambios de línea ayudan mucho.

// Saludos

pd: a mí también me gustaría saber la necesidad de los prefijos, sufijo, mejifos numéricos.