Convención de Nombres

Aunque a la hora de escribir un programa cada uno lo puede hacer como mejor le venga, en el ecosistema de programación se han establecido unas bases, digamos de buena conducta, para que sea de fácil compresión y rápida lectura por todos los que quieran hacerlo. De esa manera hoy vamos a ver los puntos más básicos.

Valor de negocio

Por ejemplo, en el código a = b * c; es sintácticamente correcto y todos los que estamos aquí sabemos que es lo que está haciendo, pero si esto mismo lo representáramos con unos nombres de variables descriptivos nos quedaría de la siguiente manera.

weeklyPay = hoursWorked * payRate;

Esto ya nos implica la intención y el significado del código fuente, como mínimo para aquellos que estén familiarizados con el contexto del programa.

Elementos comunes

Aunque se haga un convenio que más o menos es aplicable en todas partes, se tiene que tener en cuenta que las empresas y/o clientes acostumbran a tener su manera de hacer, de todas maneras vamos a ver a grandes rasgos que es lo más normal que nos podemos encontrar.

Longitud de identificadores

Una de las reglas básicas que siempre se sigue en todos los convenios es el tamaño tanto en las variables como en los métodos y clases y aunque no son reglas como tal sí que pueden ser tomadas como unas directrices.

·        Las variables han de ser descriptivas, de tal manera que los identificadores cortos han de ser preferibles por su fácil lectura.

·        Los indicadores extremadamente cortos como pueden ser “x” o “y” han de ser evitados a toda costa; estos identificadores son muy difíciles de seguir, de difícil comprensión y casi imposibles de refactorizar.

·        No se tiene que tener miedo al escribir variables largas, si es necesario tener diversas variables que hacen referencia a un mismo objeto, pero con pequeños matices es bueno tener una variable descriptiva que se entienda con un sufijo que se comprenda bien.

Identificador de varias palabras

Como ya hemos comentado es recomendable la utilización de identificadores significativos. Una sola palabra acostumbra a no ser tan significativa, o específica, como lo puede ser un conjunto de palabras. Por esa razón en Java tenemos una convención denominada “CamelCase” que veremos un poco más adelante.

·        Palabras delimitadores separados.

En Java las variables, los métodos y las clases se tienen que formar con los caracteres alfanuméricos y con el guión bajo (“_”), pero hay que tener en cuenta que no se puede empezar con un guión bajo ni con un número.

·        Eliminar espacios entre palabras.

Otro enfoque sería el de eliminar los espacios existentes marcando la siguiente palabra con mayúscula, este tipo de delimitador de palabras es denominado como capitalización medial o “CamelCase”. Si seguimos estas directrices la frase “Radio externo de la pirámide”  quedaría como “RadioExternoDeLaPiramide” o bien como “radioExternoDeLaPiramide”. Pero si nos fijamos se tratan de dos palabras radicalmente diferentes ya que Java es “case sensitive”, o lo que es lo mismo, es sensible a la diferenciación entre mayúsculas y minúsculas en una palabra, de manera que como elegir cuando poner mayúsculas al inicio y cuando no ponerlo.

Para saber cuándo usar mayúscula y minúscula en Java grandes de la industria hicieron unas directrices de muy fácil aplicación que se basan en tan solo cuatro puntos.

·        Clases: Los nombres de clases han de ser escritos en sustanivo y seguir el patrón de “Upper CamelCase”, o lo que es lo mismo con la primera letra de cada palabra en mayúsculas y sin espacios  “RadioExternoDeLaPiramide”. Se tienen que usar palabras completas, evitando los acrónimos y abreviaturas a toda costa, siempre y cuando la abreviatura no este extendida y aceptada por la comunidad, en ese caso es mejor usar la abreviatura con tal de acortar la palabra. Ex: URL, HTML, XML, …

·        Métodos: Los métodos deben de ser verbos escritos en “lower CamelCase”, con la primera letra de cada palabra en mayúsculas excepto la primera que ira en minúscula y sin espacios “radioExternoDeLaPiramide”.

·        Variables: Las variables locales, de instancia y de clase también se escriben en “lower CamelCase”

o   No pueden comenzar por guion bajo ( _ ) ni por ( $ ), aunque ambos son caracteres validos en otras posiciones.

o   Los nombres deben de ser cortos pero significativos.

o   El nombre tiene que ser mnemónico, es decir, el nombre tiene que ser diseñado para indicar al programador la intención de su uso.

o   Las variables de un solo carácter se tienen que evitar, excepto en las que sean de usar y tirar, los nombres más comunes para estas variables temporales son:

§  i, j, k, m y n  para los enteros.

§  c, d y e para los caracteres.

·        Constantes: Las constantes tienen que estar escritas en mayúsculas, además las constantes pueden contener caracteres numéricos, pero jamás en la primera posición.