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.
