Convenciones de cdigo Java:

Sun, ahora parte de Oracle, cre un conjunto de normas o convenciones o recomendaciones de

codificacin de J ava, y se publicaron las normas en un documento titulado ingeniosamente
"Convenciones de cdigo Java", que se puede encontrar en la pgina de convenciones de
cdigo de Oracle.

Aqu estn las normas de nomenclatura que se recomiendan:

Clases e interfaces: La primera letra debe ser mayscula, si varias palabras se unen para formar
un nombre cada palabra que lo conforma debe empezar con la primera letra mayscula a esto se
le llama "Camel Case", por ejemplo:

Perro
Cuenta
SistemaDeAdministracionFinanciero

Las interfaces son tpicamente adjetivos como:

Runnable
Serializable
Imprimible

Mtodos: la primera letra debe ser minscula y despus se puede aplicar la regla Camel Case,
tpicamente son pares verbo-sustantivo, por ejemplo:

calculaPeso
getBalance
obtenConexion
setNombreCliente

Variables: Similar a los mtodos, se recomiendan nombres cortos, significativos y fciles de
recordar.

nombreCompleto
porcentajeInteres
miString

Constantes: Las variables constantes son marcadas como "static" y "final". Estas se deben
nombrarse con todas sus letras maysculas y separando cada palabra con guion bajo (_), por
ejemplo:

ESTE_VALOR_NUNCA_CAMBIARA
VARIABLE_ESTATICA

Aunque no es necesario seguir estas convenciones para que nuestro cdigo compile, el hacerlo
nos ayudar cuando realicemos proyectos en equipo o que otros entiendan ms fcilmente nuestro
cdigo.


Estndares JavaBeans

Los estndares J avaBeans son acuerdos para nombrar a las clases, mtodos "set" (establecer un
valor) y "get" (obtener un valor), etc. Que tampoco estamos obligados a seguirlas pero es una
buena prctica para nosotros y para tener ms claro nuestro cdigo.

Los J avaBean son clases que contienen propiedades, estas propiedades son nombradas variables
de instancia y por lo regular, aunque deberamos tratar de que fuera siempre, las marcamos como
privadas, la nica forma de acceder a estas propiedades desde fuera de la clase es a travs de
mtodos, los mtodos que se utilizan para establecer valor a estas variables son llamados mtodos
"setters" y los mtodos para obtener el valor son llamados "getters".

Sun estableci unas reglas para nombrar a las propiedades, as como a sus mtodos "setter" y
"getter". Muchos frameworks se basan en que nuestro cdigo sigue estas reglas para poder
funcionar correctamente y, como toda regla, si no las seguimos corremos el riesgo de que algo no
funcione como lo esperamos.

Reglas para nombrar a las propiedades:
Si la propiedad no es de tipo booleano, el prefijo para un mtodo getter es "get", por
ejemplo para una variable "nombre" su respectivo mtodo getter ser "getNombre"
(aqu tambin se aplica la regla de Camel Case para separar cada palabra). Tambin hay
que tener en cuenta que no hay necesidad de que el nombre que sigue despus del prefijo
"get" sea igual al nombre de la propiedad, el nombre de la propiedad es irrelevante para el
mtodo "get" o "set".
Si la propiedad es un booleano el mtodo getter para esta propiedad puede llevar el
prefijo "get" o "is", para una propiedad booleana llamada "estado" su mtodo get vlido
puede ser "getEstado" o "isEstado".
El prefijo para el mtodo setter de una propiedad es "set", por ejemplo "setNombre"
para un atributo "nombre".
Como se menciona anteriormente en las propiedades tambin se aplica la regla camel
case, es decir, despus del prefijo "set", "get" o "is" la primera letra seguida es una letra
mayscula.
El mtodo "setter" debe ser marcado pblico con un valor de retorno void (vacio) y con
un argumento o parmetro que represente al tipo de la propiedad, por ejemplo: "public
void setNombre(String nombre){ }" para una propiedad "nombre" del
tipo String.
Los mtodos "get" tambin deben ser marcados pblicos con un valor de retorno que
represente al tipo de la propiedad y/o con el tipo de argumento o parmetro del mtodo set
para esa propiedad, por ejemplo: "public String getNombre(){ return nombre;
}" para una propiedad "nombre" del tipo String".

Estas reglas se extienden para proporcionar reglas especiales para los eventos que nuestro
sistema pueda lanzar (usualmente en aplicaciones stand alone o de escritorio)




Un evento constituye un mtodo para que una clase notifique a los usuarios de un objeto que algo
interesante sucede al objeto, como, por ejemplo, que se ha hecho clic en un control de una interfaz
grfica de usuario. Los eventos J avaBean soportan especificaciones, que permiten a los
componentes notificar a otros cuando algo sucede. El modelo de eventos se utiliza a menudo en
aplicaciones de interfaz grfica de usuario (GUI) cuando un evento como un clic del ratn es de
multidifusin a muchos otros objetos que pueden tener cosas que hacer cuando se produce el clic
del ratn. Los objetos que reciben la informacin que se produjo un evento se llaman "listeners"
(oyentes). Se necesita saber que los mtodos que se utilizan para aadir o eliminar los listeners de
un evento tambin debe seguir las normas de nomenclatura J avaBean:

Reglas para nombrar a los listeners:
Los nombres de los mtodos listeners usados para "registrar" un listener con un evento
debe usar el prefijo "add" seguido del tipo de listener, por ejemplo:
"addActionListener".
Los nombres de los mtodos usados para "eliminar" un listener debe usar el prefijo
"remove", seguido del tipo de listener.
El tipo de listener que se registra o elimina debe ser pasado como argumento al mtodo.
Los listeners deben terminar con la palabra "Listener".

Ejemplo de mtodos J avaBeans vlidos:

public void setMyValue(int v)
public int getMyValue()
public boolean isMyStatus()
public void addMyListener(MyListener m)
public void removeMyListener(MyListener m)

Ejemplo de mtodos J avaBeans invlidos:

void setNombreCliente(String s) // debe ser publico
public void modificarMiValor(int v) // no puede usar 'modificar'
public void addXListener(MyListener m) // No coinciden los tipos