Mejora tu código: crea nombres de variables descriptivos

Los nombres de variables descriptivos ayudan a mejorar la legibilidad de tu código

A veces estamos frente a la pantalla y todo está lleno de ese código hermoso que hemos creado. Pero, llega el punto en el que necesitas una revelación: ¿Qué nombre puedo poner a esta variable, o a esta clase, o a esta función?

El flujo de trabajo se corta por un momento y la vida se vuelve complicada.Todo programador ha pasado por eso. Algunos deciden no tomarse tan en serio el asunto y otros se obsesionan. Los segundos están en el camino correcto.

Dentro del mundo de la programación existen una gran cantidad de estándares, tecnologías, lenguajes y técnicas utilizadas para crear mejor código. 

Algunas veces pueden ser de naturaleza intrincada y otras veces suelen ser muy simples. Este es el caso de los nombres de variables descriptivos.

Los nombres de variables son importantes

Aunque a veces pasamos por alto el asunto, la verdad es que los nombres de variables suelen indicarnos qué significado tiene para nosotros un valor o dato dentro del estado de nuestro programa. De este modo, es más fácil saber la función del mismo dentro de nuestro código.

Ecuación del Teorema de Pitágoras. Usada para ejemplificar porqué son importantes los nombres de variables descriptivos Cuando tenemos ecuaciones como estas, bastante conocidas, quizás no sea tan importante el nombre que coloquemos. Pero en el caso de nuestras propias ecuaciones sí tendremos que ser más específicos.

Esto es vital, sobre todo, si formamos parte de un equipo para el que resultan importantes las convenciones de código.

En la ecuación sp = ss / p no resulta para nada obvio que estamos calculando el sueldo promedio de ciertos empleados.

Todo cambia si en su lugar tuviésemos esto: sueldo_promedio = suma_de_sueldos / cantidad_de_personal.

Tanto si estás en un proyecto en solitario o trabajas con un equipo, esto es una buena práctica.

Suele suceder que unas cuantas horas después de haber escrito un trozo de código suficientemente grande, su significado y función se tornen confusos.

Esto es causado por diferentes factores: demasiado código escrito en poco tiempo, estrés, distracciones, cansancio y pare usted de contar…

Esta confusión crece en intensidad si, además de no comentar tu código, tus nombres de variables (o de funciones) no describen bien su significado y objetivo dentro del código.

La solución: usar nombres de variables descriptivos.

Cada lenguaje, o comunidad de programadores alrededor de cierto lenguaje, tiene sus propias convenciones para los nombres variables u otros elementos.

Cada lenguaje de programación tiene sus propias reglas para nombrar a una variable ¡Por favor, concédete un momento de tu vida para leerlas!

Además, la comunidad alrededor de un lenguaje se encarga de crear convenciones útiles que se convierten en un estándar.

Puedes ver el hilo original aquí.

PHP, Python y otros lenguajes cuentan con comunidades que se toman el trabajo de crear estas convenciones, para que el resto de programadores que las considere útiles las sigan.

Incluso si no son las mejores para ti, es mejor, en este caso, tener algo que sirva de guía. Aunque los programadores no son nada ilógicos y tras cada regla hay un porqué.

Entonces: son mejores estas reglas con un porqué, que no tener reglas y ni siquiera saber porqué no tienes reglas.

Ver más comentarios curiosos en el código

Además de los nombres de variables, las convenciones también incluyen la organización de archivos, la indentación, los comentarios, las declaraciones, los espacios en blanco, las llaves de apertura y cierre y más.

Convención de nombres: desde el CamelCase hasta el kebab-case

Hagamos un recorrido a través de las diferentes convenciones de nombres que te puedes conseguir en este mundillo del código.

CamelCase

Su nombre se debe a la semejanza entre las jorobas de un camello y las letras en mayúscula a lo largo del nombre o identificador de la variable.

Existen dos tipos de CamelCase:

UpperCamelCase 

Cuando la primera letra de cada una de las palabras es mayúscula. Ejemplo: ApokPasionPorLasIdeas.

lowerCamelCase 

En este caso la primera letra es minúscula. Ejemplo: apokPasionPorLasIdeas.

Esta convención es muy usada en lenguajes de programación como PHP, Java, C# o Js.

snake_case

Snake case es una convención en donde las palabras que conforman el nombre se cortan usando un guión bajo. Por ejemplo: apok_pasion_por_las_ideas.

Nota que ninguna palabra comienza con mayúsculas.

Esta convención se asocia con lenguajes “antiguos”, particularmente con C. Aunque también lenguajes como Ruby y Python lo han adoptado.

kebab-case

Al igual que el snake_case pero unido con guiones en vez de barra baja. Por ejemplo: apok-pasión-por-las-ideas.

Acá nos encontramos con el Train-Case, una variedad del kebab-case, en la que cada palabra tiene una primera letra en mayúsculas. Por ejemplo, Apok-Pasion-Por-Las-Ideas.

l33t

Leet (o “1337”), también conocido como eleet o leetspeak, es una nomenclatura usada por algunas comunidades y usuarios de diferentes medios de internet. 

Utiliza algunos caracteres similares a otros y los reemplaza. Por ejemplo, las ortografías de leet de la palabra leet incluyen 1337 y l33t.

Es bastante utilizado en internet en términos como n00b, l0l,C@7L0vr, 0wn3d o r00t. 

Notación húngara

Su nombre proviene del hecho de que su inventor, Charles Simonyi, nació en Hungría.

En esta notación a los nombres de variable se les coloca un sufijo seguido de una palabra que describa precisamente su función en el programa.

El sufijo es colocado en minúscula e indica el tipo de dato de la variable.

Lo importante es ser descriptivo

Toma en cuenta los ejemplos anteriores. Ya que, aunque las convenciones son buenas, es común que los equipos tengan sus propios sabores en cuanto a estas.

Por lo tanto, lo que debemos buscar a toda costa es ser descriptivos. Intentar que nuestro código sea legible sin necesidad de tener que dar demasiadas explicaciones.

Pues, si bien es cierto que los comentarios ayudan, no quieres tener un código completamente lleno de líneas y líneas de comentarios que al final solo ofuscan el código.