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.