Guia del desarrollador: Nomenclatura III

Como no hay dos sin tres, aquí va el tercer artículo sobre recomendaciones al respecto de la nomenclatura en nuestras aplicaciones.

Tercera ley de la nomenclatura: Distinciones si, pero razonadamente.

A veces, nos vemos tentados a añadir pequeñas variaciones ortográficas solo por el mero hecho de que ya se ha usado el nombre con anterioridad. Si eso es así, entonces debemos revisar la nomenclatura. Si hay un cambio razonado, debe aportar sentido.

Aquí proporcionamos una serie de consejos breves al respecto:

1.- A veces los nombres no desinforman pero no aportan información. Así, la función:

public void orderArrayInArray(int[] arg1, int[] arg2) { … }

 

Se entiende mejor cuando cambiamos los nombres de los parámetros por:

public void orderArrayInArray(int[] source, int[] destination) { … }

 

 

2.- Cuidado con las palabras “adicionales”. Por ejemplo, si tenemos dos clases User y UserInfo/UserData estamos creando una duplicidad ya que representan el mismo concepto. Los sufijos Info y Data aportan el mismo significado a nuestra clase.

3.- Como en las definiciones de un examen, la palabra definida no debe estar en la definición. No debemos usar palabras como variable, table, String,… que no aportan nada extra.

Cuarta ley de la nomenclatura: Utiliza nombres pronunciables

Muchos antiguos programadores se han visto en la tesitura de tener que ahorrar caracteres en el nombre de sus variables. Pues bien, eso ya no sucede así que no vamos a complicarnos la vida llamando a nuestra clase DtaRcrdMgr cuando podemos llamarla DataRecordManager.

Quinta ley de la nomenclatura: ¿Y si quiero buscarlo?

En ocasiones, queremos ver que uso concreto se hace de una variable. Pero… ¿qué pasa si nuestra variable se llama i o as o te? ¿Cuántas ocurrencias aparecerán de esa combinación de letras? ¿Y si lo que buscamos es un número como 0 o 1?

En esos casos, declara una variable con un nombre con sentido y que aporte información. Utiliza variables con una sola letra en métodos donde se usen de forma local y define “contantes” si es necesario.

public final int DAYS_IN_WEEK = 7;

Sexta, séptima, octava y novena leyes de la nomenclatura: No te compliques la vida.

Resumiendo:

• No uses nombres en clave o codificados.
• No codifiques los tipos en los nombres de variables (No se actualizan!).
• No añadas prefijos “m_” a variables miembro, las clases deben tener el tamaño suficiente para que no sea necesario.
• No utilices asociaciones mentales, las mentes no se leen, el código si.

Que si, insisto, que… ¡La nomenclatura importa!

 

Si no pudiste leer los artículos anteriores de La Guía del Desarrollado:

Guia del desarrollador: Nomenclatura I
Guia del desarrollador: Nomenclatura II

---

Si quieres ampliar tus conocimientos de programación, SEAS imparte mucha formación relacionada, como por ejemplo el Máster en Desarrollo de Aplicaciones Multiplataforma, con el que podrás aprender a gestionar y desarrollar software para escritorio, web y móvil.