Ir al contenido principal

Convenciones de nombrado

¿Qué son?
Las convenciones de nombrado son un conjunto de reglas para nombrar identificadores (nombres de variables, clases, propiedades, funciones, etcétera) dentro de un lenguaje de programación. No son requeridas por el compilador o interprete para que el programa funcione, son un estilo en la forma de escribir el programa.

¿Por qué utilizar convenciones de nombrado? ¿Cuáles son las ventajas?
El utilizar una convención de nombrado dará al código un estilo consistente que ayuda a la lectura para el resto del equipo o incluso para el mismo desarrollador que lo escribió. Es fácil saber que esta pasando con sólo ver el estilo utilizado. Similar a como ocurre al leer un libro.  Algunos autores usan diferentes formatos a lo largo de los libros (itálica para ciertas partes del texto, recuadros con otro tipo de letra, etcétera) estos sirven para que el lector tenga un mejor contexto de lo que esta leyendo.

Denota cierta intención. Si la notación es consistente, a lo largo del programa, con sólo leer un fragmento del código podemos descubrir lo que se intenta (y como) lograr. El no seguir una convención puede requerir que el lector tenga que leer más del código para poder entender mejor el contexto y el objetivo de cada variable o procedimiento.

Muestra que él código fue escrito por un profesional, esto pareciera no ser importante; pero al momento de tener que mantener código de otras personas (o de uno mismo) es más agradable trabajar con código escrito de manera profesional.

¿Cuáles serían las desventajas?
La mayoría de las desventajas aparecen cuando se sigue una convención equivocada o "anticuada", sí, me refiero a la notación húngara.

¿Por qué no me gusta la notación húngara?
La Notación Húngara consiste en usar prefijos en el nombre de las variables, dependiendo del tipo. Esta notación la utilizaba en la escuela y en los primeros proyectos en los que participé saliendo de ella. Era común en lenguajes como Delphi y VisualBasic al momento de nombrar los componentes (controles) utilizados.

Algo que noté como desventaja era que tenía que recordar cual era el prefijo para la variable que iba a declarar. Por ejemplo, actualmente si voy a definir un botón para guardar cambios puedo llamarlo saveButton, con lo cual es claro ver que se trata de un botón para guardar; Pero con la notación húngara tenía que recordar cual era ese prefijo para los botones antes de poder nombrar mi variable btnSave. Esto se complicaba más entre menos común fuera el control a utilizar. Había ocasiones que perdía tiempo definiendo prefijos y después buscándolos para poder así nombrar variables y el código fuera consistente.

En otras ocasiones son totalmente innecesarios los prefijos y sólo sirven para meter ruido y hacer más difícil la lectura del código. Tomemos como ejemplo  el siguiente calculo:

Sin notación húngara
    item.amount =  unitPrice * quantity;

Con notación húngara
    oItem.fAmount = fUnitPrice * iQuantity;

En una sola línea de código se ve que tenemos ruido innecesario, en programas algo grandes el ruido que introducen los prefijos llega a ser muy molesto.
Las convenciones varían según el lenguaje
Es importante conocer la convención de nombrado utilizada (recomendada) para el lenguaje que estamos utilizando, estas varían de leguaje a lenguaje. Aun y que estemos usando varios lenguajes en un mismo proyecto las convenciones pueden (y deben) cambiar según el lenguaje en uso.

Por mi trabajo es común ver JavaScript, HTML, CSS (incluso SQL) escrito siguiendo convenciones de C# lo cual no creo que sea correcto (sin tomar en cuenta lo mucho que me molesta). En esos casos se esta desaprovechando las ventajas de usar una convención, se hace más complejo leer la intención del código.

Al final de lo que se trata es de poner atención en que el código sea fácil de leer y entender. Para esto debe ser escrito de una manera profesional, siguiendo las convenciones comunes para el lenguaje. Cuando el código no sigue la convención del lenguaje  es fácil dudar de la experiencia (profesionalismo) que tenía el desarrollador  en ese lenguaje en particular (al momento de escribirlo), por lo tanto se  tendría que revisar más código para saber si el código hace lo que suponemos y que  además que lo haga de la mejor manera.

Comentarios

  1. Estoy de acuerdo contigo en que la notación húngara produce ruido innecesario al código. La mayoría de las veces se puede saber si la variable es un entero, objeto o cualquier otro tipo con sólo ver el nombre.

    Es importante establecer las convenciones en un proyecto desde el inicio e informar a los nuevos integrantes sobre ellas cuando se haga un code review. Sí es muy feo ver variables del tipo "x" "i" sin saber su funcionamiento e intención a simple vista. No hay excusa para no hacerlo, hace que tu código sea legible por quienes están interesados sobre lo que hace y lo más importante, lo hace legible para ti mismo cuando quieras revisitarlo y modificar alguna funcionalidad

    ResponderBorrar

Publicar un comentario

Entradas más populares de este blog

Bloqueos

Una de las preguntas típicas de las juntas matutinas en los equipos de desarrollo de software es ¿Hay algún bloqueo? Si lo hay, se trata de ver qué es lo que está esperando esa persona y encontrar la forma de que se desbloquee; pero ¿Qué son los bloqueos? Los bloqueos son obstáculos que te impiden realizar o avanzar en tu trabajo. Evitan que puedas seguir progresando en el proyecto.

He notado que es común en las personas con menos experiencia decir que tienen un bloqueo cuando están batallando, debido a su poca experiencia, en la forma de resolver un problema. Han intentado varias formas y se empiezan a quedar sin ideas de como puede ser resuelto el problema o como pueden cumplir con el requerimiento especificado. Al quedarse sin opciones de qué intentar dicen que tienen un bloqueo con la tarea y que a menos que alguien les diga como resolverlo, no se puede avanzar en la tarea.

En personas con más experiencia, ese tipo de bloqueos no ocurren, una persona con experiencia ha visto pro…

Firebird 2.1 UPDATE OR INSERT

Another great feature that I like in Firebird 2.1 is the UPDATE OR INSERT statement. It's a really time saver and it makes the SQL cleaner.

For example suppose I have a products table like the one I use in my last post and an inventory table to store the product stock. Before Firebird 2.1 if I want to set the stock for a product I needed to check if a record for that product_id already exists; if the product_id already exists then I write an update. If not then I write an insert statement. So I ended up with something like this:


IF EXISTS(SELECT * FROM inventory WHERE product_id = :product_id ) THEN
UPDATE
inventory
SET
stock = :stock
WHERE
product_id = :product_id;
ELSE
INSERT INTO inventory
(product_id, stock)
VALUES
(:product_id, :stock);

In this example I only update one field but when I have to update a big table I ended up with a big chunk of code and thinking: "there should be another (better) way to do this".

Fortunately now with Firebird 2.1 there…

Database Mail en MS SQL Server 2005

Configuración de Database Mail en MS SQL Server 2005

Primero se debe de habilitar, ya que por omisión el componente esta deshabilitado, Utilizando el SSMS (SQL Server Management Studio)


Si no esta habilitado aparecerá un mensaje preguntado si lo habilita, después aparece esta ventana donde se pregunta al usuario que es lo desea hacer.


Seleccionamos la primera opción para crear un perfil.


Configuramos el perfil y le agregamos por lo menos una cuenta.


Seleccionamos el perfil como public y default.


Para mandar correo se utiliza el procedimiento msdb.sp_send_dbmail por lo tanto el usuario que intente mandar correo debe de tener permiso para la base de datos msdb.

Referencias:
http://www.sqlservercentral.com/columnists/cBunch/introtodatabasemailinsql2005.asp