Convenciones de cdigo

El presente documento trata sobre las convenciones en la codificacin de programas en Java, estas
convenciones son proporcionadas por Sun, en su original en ingls.
He aqu el contenido
1. Introduccin
1.1 Porqu tenemos convenciones de cdigo
1.2 Reconocimientos
2. Nombres de archivos
2.1 Sufijos de archivo
2.3 Nombres de archivo comunes
3. Organizacin de archivos
3.1 Archivos fuente en Java
3.1.1 Comentarios iniciales
3.1.2 Sentencias de declaracin de paquete e importacin
3.1.3 Declaraciones de interfaz
4. Tabulaciones y sangras
4.1 Longitud de lnea
4.2 Ajuste de lneas
5. Comentarios
5.1 Formatos de implementacin de comentarios
5.1.1 Comentarios de bloque
5.1.2 Comentarios de lnea simple
5.1.3 Comentarios de rastreo
5.1.4 Comentarios de fin de lnea
5.2 Comentarios de documentacin
6. Declaraciones
6.1 Nmero por lnea
6.2 Inicializacin
6.3 Ubicacin
6.4 Declaraciones de clase e interfaz
7. Sentencias
7.1 Sentencias simples
7.2 Sentencias compuestas
7.3 Sentencias return
7.4 Sentencias if, if-else, if-else-if-else
7.5 Sentencias for
7.6 Sentencias while
7.7 Sentencias do-while
7.8 Sentencias switch
7.9 Sentencias try-catch

8. Espacios en blanco
8.1 Lneas en blanco
8.2 Espacios en blanco
9. Convenciones sobre los nombres
10. Prcticas de programacin
10.1 Proveer acceso a variables de instancia y clase
10.2 Referenciar variables de clase y mtodos
10.3 Constantes
10.4 Asignacin de variables
10.5 Prcticas diversas
10.5.1 Parntesis
10.5.2 Retorno de valores
10.5.3 Expresiones antes del operador condicional "?"
10.5.4 Comentarios especiales
11. Ejemplo de cdigo
11.1 Ejemplo de cdigo fuente Java

1 Introduccin
1.1 Porqu tenemos Convenciones de Cdigo?

Las convenciones de cdigo son importantes para los programadores por un nmero de razones:

El 80% del tiempo de vida de un software es de mantenimiento

Apenas algn software es mantenido toda su vida por su autor original.
Las convenciones de cdigo proveen legibilidad al software, permitiendo a los ingenieros entender cdigo nuevo
ms rpido y mejor.
Si usted expide su cdigo fuente como un producto, usted necesita asegurarse que tambin se empaqueta y
limpia como cualquier otro producto que disee.

Para trabajar con las convenciones de cdigo, todas las personas que escriben el software deben adaptarse a las
convenciones de cdigo. Todas.

1.2 Reconocimientos

Este documento refleja los estndares de Java presentados en la Especificacin de Lenguaje Java de Sun Microsystems,
Inc. Las mayores contribuciones son de Peter King, Patrick Naughton, Mike DeMoney, Jonni Kanerva, Kathy Walrath y
Scott Hommel.

2 Nombres de archivos

Esta seccin lista los sufijos y nombres de archivo ms comnmente usados.

2.1 Sufijos de archivo

El Software Java usa los siguientes sufijos de archivo.

Tipo de Archivo

Sufijo

Cdigo Fuente Java

.java

Java bytecode

.class

2.2 Nombres de archivo comunes

Nombre de
Archivo

Uso

GNUMakefile

El nombre preferido para archivos hechos,

Nosotros usamos gnumake para contruir
nuestro software.

README

EL nombre preferido para el archivo que

resume los contenidos de un directorio en
particular

3. Organizacin de los archivos

Un archivo consiste de secciones que deben estar separadas por lneas en blanco y un comentario opcional identificando
a cada seccin.
Los archivos mayores a 2000 lneas son engorrosos y deben evitarse.
Si quiere un ejemplo de un programa en Java formateado apropiadamente vea el "Ejemplo de Cdigo fuente Java" en la
seccin 11.1.

3.1 Archivos Fuente en Java

Cada archivo fuente consta de solamente una clase, o interfaz, pblica. Se puede poner en el mismo archivo fuente a las
clases o interfaces privadas asociadas a la clase pblica. La clase pblica debe ser la primera clase o interfaz en el
archivo.
Los archivos fuente Java tienen el siguiente orden:

Comentarios iniciales (vea la seccin 3.1.1)

sentencias de declaracin de paquete e importacin.
Declaraciones de clase o interfaz (vea "Declaraciones de Clase e Interfaz", en la seccin 3.1.3).

3.1.1 Comentarios iniciales

Todos los archivos fuente deben comenzar con un comentario estilo C te resuma el nombre de la clase, su informacin de
la versin, fecha y una nota de copyright.
/*
* Nombre de la clase
*
* Informacin de la versin
*
* Fecha
*
* Nota del copyright
*/

3.1.2 Sentencias de declaracin de paquete e importacin

Las primera lnea no comentadas de la mayora de cdigo fuente Java es la sentencia package. Despus de ella pueden
seguir las sentencias import, por ejemplo:
package java.awt;
import java.awt.peer.CanvasPeer;

3.1.3 Declaraciones de clase o interfaz

La siguiente tabla describe las partes de una declaracin de clase, o interfaz, en el orden en el que deben aparecer. Vea
el "Ejemplo de cdigo fuente Java" en la seccin 11.1 si desea un ejemplo que incluye comentarios.

Partes de la declaracin de clase o

interfaz

Notas

Comentario de documentacin de la clase o

Vea "Comentarios de documentacin" en la seccin 5.2.
interfaz. (/** ... */)

Sentencia class o interface

Este comentario debe tener cualquier informacin

Comentario de implementacin de la clase o
complementaria de la clase o interfaz que no sea apropiada
interfaz (/*...*/) si es necesario.
para el comentario de documentacin.

Variables de tipo static

Primero las pblicas (public), luego las protegidas

(protected), luego las de nivel de paquete (sin acceso a
modificacin), y luego las privadas (private).

Variables de instancia

Primero las pblicas (public), luego las protegidas

(protected), luego las de nivel de paquete (sin acceso a
modificacin), y luego las privadas (private).

Constructores

Mtodos

Esos mtodos deben estar agrupados por funcionalidad antes

que por alcance o accesibilidad. Por ejemplo, un mtodo
privado puede estar entre dos pblicos. La meta es lograr
que la lectura y compresin del cdigo sea fcil

4. Tabulaciones y sangras
Se deben usar cuatro espacios como unidad de sangrado. La elaboracin exacta del sangrado (espacio vs. tabulaciones)
no se especifica. Las tabulaciones deben se exactamente cada 8 espacios (no 8).

4.1 Longitud de lnea

Hay que evitar las lneas de ms de 80 caracteres, puesto no son bien manejadas por muchas terminales y herramientas.
Nota: Los ejemplos usados en este documento tienen lneas de longitud corta, generalmente no ms de 70 caracteres.

4.2 Ajuste de lneas

Cuando una expresin no se ajustar en una sola lnea, hay que cortarla de acuerdo con estos principios generales:

Corte despus de una coma.

Corte antes de un operador
Es mejor preferir los cortes de alto nivel que los cortes de bajo nivel.
Alinee la nueva lnea con el comienzo de la expresin en el mismo nivel sobre la lnea previa.
Si las reglas citadas llevan a cdigo confuso o a cdigo apiado al margen derecho, ajuste la sangra 8 espacios
en su lugar.

Aqu hay algunos ejemplo de formas de cortar lneas:

algunMetodo(expresionLarga1, expresionLarga2, expresionLarga3,
expresionLarga4, expresionLarga5);
var = algunMetodo1(expresionLarga1,
algunMetodo2(expresionLarga2,
expresionLarga3));
Los siguientes son dos ejemplo de ajuste de lnea en expresiones aritmticas. Es preferible el primer mtodo, puesto que
el corte ocurre fuera de la expresin entre parntesis, la cual es de alto nivel.
longName1 = longName2 * (longName3 + longName4 - longName5)
+ 4 * longname6; // PREFERIBLE
longName1 = longName2 * (longName3 + longName4
- longName5) + 4 * longname6; // OLVIDE ESTA FORMA

Los siguientes son dos ejemplo de sangrado en las declaraciones de mtodos. La primera es el tipo convencional. La
segunda alternar la segunda y la tercera lneas ms a la derecha que si se usara sangrado convencional, en lugar de eso
se sangra slo 8 espacios
//SANGRADO CONVENCIONAL
algunMetodo(int anArg, Object anotherArg, String yetAnotherArg,
Object andStillAnother) {
...
}
//SANGRADO DE 8 ESPACIOS DEJANDO DE LADO SANGRADOS MUY PROFUNDOS
private static synchronized nombreLargoDeMetodo(int unArg,
Object otroArg, String todaviaOtroArg,
Object otroMas) {
...
}
El ajuste de lnea para sentencias if deben usar generalmente la regla de 8 espacios, puesto que el sangrado
convencional (de 4 espacios) hace difcil ver el cuerpo del cdigo. Por ejemplo:
//NO USE ESTE SANGRADO
if ((condicion1 && condicion2)
|| (condicion3 && condicion4)
||!(condicion5 && condicion6)) { //MAL AJUSTADO
hacerCualquierCosa(); //HACE ESTA LNEA FACIL DE PERDER
}
//USE ESTE SANGRADO EN SU LUGAR
if ((condicion1 && condicion2)
|| (condicion3 && condicion4)
||!(condicion5 && condicion6)) {
hacerCualquierCosa();
}
//O USE ESTE
if ((condicion1 && condicion2) || (condicion3 && condicion4)
||!(condicion5 && condicion6)) {
hacerCualquierCosa();
}
Aqu hay tres formas permisibles de formatear expresiones ternarias.
alfa = (unaExpresionBooleanaGrande) ? beta : gama;
alfa = (unaExpresionBooleanaGrande) ? beta
: gama;
alfa = (unaExpresionBooleanaGrande)
? beta
: gama;

5. Comentarios
Los programas Java pueden tener dos formas de comentarios: comentarios de implementacin y comentarios de
documentacin. Los comentarios de implementacin son aquellos encontrados en C++, los cules stn delimitados por
/*...*/, y //. Los comentarios de documentacin (conocidos como "comentarios doc") son slo Java, y estn
delimitados por /**...*/. Los comentarios doc pueden extraerse a archivos HTML usando la herramienta javadoc.
Los comentarios de implementacin son formas para comentar cdigo o para comentar una implementacin particular.
Los comentarios doc sirven para describir la especificacin del cdigo, desde una perspectiva de aplicacin libre para que
lean los desarrolladores que no necesariamente tienen el cdigo fuente a la mano.

Los comentarios deben usarse para conseguir resmenes del cdigo y proveer informacin adicional que es difcil de
obtener del cdigo en si. Los comentarios deben contener slo la informacin que sea relevante para la lectura y
entendimiento del programa. Por ejemplo, la informacin acerca de como se arma el paquete correspondiente o en que
directorio est, no deben estar incluidos como comentarios.
La discusin sobre las decisiones del diseo, si son triviales u obvias, es buena, pero hay que evitar la informacin
duplicada que este presente en el cdigo (y desaparecerla). Los comentarios redundantes tambin se se vuelven
obsoletos con mucha facilidad. En general, hay que evitar cualquier comentario que probablemente est de ms a medida
que el cdigo evolucione.
Nota: La frecuencia de comentarios algunas veces refleja una calidad pobre de cdigo. Cuando se sienta obligado a
agregar un comentario, considere reescribir el cdigo para hacerlo ms claro.
Los Comentarios no deben estar encerrados en grandes cajas de asteriscos u otros caracteres
Los comentarios nunca deben contener caracteres especiales como alimentacin de pgina o retroceso.

5.1 Formatos de implementacin de comentarios

Los programas pueden tener cuatro estilos de comentario: bloque, lnea simple, rastreo y fin de lnea.

5.1.1 Comentarios en bloque

Los comentarios en bloque se usan para describir archivos, mtodos, estructuras de datos y algoritmos. Los comentarios
en bloque pueden usarse al comienzo de cada archivo y antes de cada mtodo. Tambin se les puede usar en otros
lugares, dentro del cuerpo de los mtodos. Los comentarios en bloque dentro de una funcin o mtodo deben sangrarse
al mismo nivel del cdigo que est describiendo. Un comentario en bloque debe estar precedido por una lnea en blanco
para que est aparte del resto del cdigo.
/*
* AQUI HAY UN COMENTARIO EN BLOQUE
*/
Los comentarios en bloque pueden comentzar con /*-, la lnea significa sangrado(1) como el comienzo de un comentario
en bloque que no debe reformatearse. Ejemplo:
/** Aqu est un comentario en bloque con un formato muy especial
* en el que se ignora el sangrado(1).
*
*
uno
*
dos
*
tres
*/
Nota: Si no desea usar el sangrado(1), no tiene que usar /*- en el cdigo, o hacer cualquier otra concesin a la
posibilidad de que alguien ms pueda aplicar sangra (1) en el cdigo.
Vea tambin "Comentarios de documentacin" en la seccin 5.2.

5.1.2 Comentarios de lnea simple

Pueden aparecer comentarios cortos en una lnea simple sangrada al nivel del cdigo que le sigue. Si un comentario no
puede escribirse en una lnea, entonces debe usar los comentarios en bloque (vea la seccin 5.1.1). Un comentario de
lnea debe estar precedido por una lnea en blanco. Aqu hay un ejemplo de comentario de lnea:
if (condition) {
/* Handle the condition. */

...
}

5.1.3 Comentarios de rastreo

Pueden aparecer tambin comentarios muy pequeos sobre la misma lnea que e comentario describe, pero deben estar
lo suficientemente separados de las sentencias. Si aparece ms de un comentario corto en un trozo de cdigo, todos
stos deben sangrarse al mismo nivel. Aqu est un ejemplo de de un comentario de rastreo.
if (a == 2) {
return TRUE; /* caso especial */
} else {
return isPrime(a); /* trabaja solo para un 'a' impar */
}

5.1.4 Comentarios de fin de lnea

El delimitador de comentario // puede comentar una lnea completa o parcial. No puede usarse en ms de una lnea
consecutiva para comentar secciones de cdigo. Los siguientes ejemplos son de los tres estilos:
if (foo > 1) {
// Hace un doble lanzamiento.
...
}
else{
return false;
// Explica porqu aqu.
}
//if (bar > 1) {
//
//
// Hace un triple lanzamiento.
//
...
//}
//else{
//
return false;
//}

5.2 Comentarios de documentacin

Nota: vea el "Ejemplo de cdigo fuente Java" en la seccin 11.1 para ejemplos de los comentarios descritos aqu.
Para mayores detalles, vea "Cmo escribir comentarios doc para Javadoc" que incluye informacin sobre las etiquetas de
los comentarios doc (@return, @param, @see).
Para mayores detalles acerca de los comentarios doc y javadoc, vea la pgina de javadoc.
Los comentarios doc describen las clases, interfaces, constructores, mtodos y campos. Cada comentario doc esta
establecido dentro de los delimitadores de comentario /**...*/, con un comentario por clase, interfaz, o miembro. Este
comentario debe aparecer justo antes de la declaracin.
/**
* La clase Ejemplo provee...
*/
public class Ejemplo { ...
Note que las clases de alto nivel y las interfaces no se sangran, mientras que sus miembre si. La primera lnea de
comentarios doc (/**) para las clases y las interfaces no se sangran, las subsecuentes lnea de comentarios tienen un
espacio de identacin (para alinear los asteriscos verticalmente). Los miembros, incluyendo los constructores, tienen 4
espacios para la primera lnea de comentario doc y cinco espacios despus.

Si necesitamos dar informacin acerca de una clase, interface, variable, o mtodo que no es apropiada para ser incluida
en la documentacin, use un comentario de bloque (vea la seccin 5.1.1) o de lnea simple (vea la seccin 5.1.2)
inmediatamente despus de la declaracin. Por ejemplo, los detalles acerca de la implementacin de una clase debe ir en
un comentario de bloque seguido de la sentencia class, no en el comentario doc de la clase.
Los comentarios doc no deben ponerse dentro de un mtodo o en el bloque de definicin de un constructor, porque java
asocia los comentarios de documentacin con la primera declaracin despus del comentario.

6. Declaraciones:
6.1 Nmero por lnea
Se recomienda una declaracin por lnea puesto que de esta forma se pueden hacer comentarios. en otras
palabras
int level; // nivel de identacin
int size; // tamao de la tabla

Se prefiere a:
int level, size;

No ponga diferentes tipos en la misma lnea, por ejemplo:

int foo, fooarray[]; // MAL!

Nota: los ejemplos citados usan un espacio entre el tipo y el identificador. Otra forma aceptable es usando
tabulaciones, por ejemplo:
int
int
Object

level; // nivel de identacin

size; // tamao de la tabla
currentEntry; // entrada actual de la tabla

6.2 Inicializacin
Pruebe inicializando variables locales al declararlas. La nica razn para no inicializarl una varaiale al
declararla es que el valor inicial dependa de alguna operacin.
6.3 Ubicacin
Ponga las declaraciones en los bloques de inicio. (Un bloque es cualquier cdigo delimitados por las llaves "{"
y "}") No espere a declarar las variables hasta que tenga que usarlas; esto puede confundir a los programadores
incautos y entorpece la portabilidad de cdigo.
void myMethod() {
int int1 = 0; // bloque inicial del metodo
if(condicion) {
int int2 = 0; // comienzo del bloque "if"
...
}
}

La nica excepcin a esta regla son los ndices de los bucles for:
for (int i = 0; i < maxLoops; i++) { ... }

Evitar las declaraciones locales que solapen las declaraciones en niveles ms altos. Por ejemplo, no declare la
misma variable en un bloque interior
int count;
...
myMethod() {
if (condicion) {
int count; // EVITELO!
...
}
...
}

6.4 Declaraciones de clase e interfaz

Cuando escriba clases e interfaces en Java, se deben seguira las siguientes reglas de formato:

No espacios entre el nombre del mtodo y los parntesis "(" que inicia la lista de parmetros.
La llave de apertura "{" aparece al final en la misma lnea de la sentencia de declaracin.
La llave de cierre "}" inicia un lnea y se identa al nivel de la declaracin, excepto cuando se trata de una
sentencia nula, entonces el "}" aparece inmediatamente despus del "{".

class Sample extends Object {

int ivar1;
int ivar2;
Sample(int i, int j) {
ivar1 = i;
ivar2 = j;
}
int emptyMethod() {}
...
}

Los mtodos estn separados por una lnea en blanco

7. Sentencias
7.1 Sentencias simples
Cada lnea debe contener a lo sumo una sentencia. Ejemplo:
argv++; // Correcto
argc++; // Correcto
argv++; argc--; // EVITELO!

7.2 Sentencias compuestas

Las sentencias compuestas son sentencias que contienen listas de sentencias encerradas en llaves "{ sentencias }".
Vea las siguientes secciones para obtener ejemplos.

Las sentencias encerradas deben identarse un o ms niveles que la sentencia compuesta

La llave de apertura debe estar al final de la lnea que comienza la sentencia compuesta; la llave de cierre debe
empezar una lnea y estar sangrada al nivel del inicio de la sentencia compuesta.

Las llaves se usan encerrando todas las sentencias, an sentencias simples, cuando son parte de una estructura
de control, como un if-else o una sentencia for. Esto hace fcil agregar sentencias sin introducir errores
accidentalmente por olvidar poner las llaves.

7.3 Sentencias return

Una sentencia return con un valor no debe usar parntesis a menos que haga ms obvio el valor de retorno. Por
ejemplo.
return;
return myDisk.size();
return (size ? size : defaultSize);

7.4 Sentencias if, if-else, if else- if else

Las sentencias de tipo if-else deben tener la siguiente forma:
if (condicion) {
sentencias;
}
if (condicion) {
sentencias;
} else {
sentencias;
}
if (condicion) {
sentencias;
} else if (condicion) {
sentencias;
} else {
sentencias;
}
Nota: las sentencias if siempre usan llaves. Evite la siguiente forma que propende al error:
if (condicion) // EVITELO! ESTA FORMA OMITE LAS LLAVES!
sentencia;

7.5 Sentencias for

Una sentencia for debe tener la siguiente forma:
for (inicializacin; condicin; actualizacin) {
sentencias;
}
Una sentencias for vaca (una en la cul todo el trabajo se termina con las clasulas de inicializacin, condicin y
actualizacin) debe tener la siguiente forma:
for (inicializacin; condicin; actualizacin);
Cuando use el operador coma en las clasulas de inicializacin o actualizacin de una sentencia for, evite la complejidad
de usar ms de tres variables. Si es necesario, use sentencias separadas antes del bucle for(para la clasula de
inicializacin) o al final del bucle (para la clasula de actualizacin).

7.6 Sentencias while

Una sentencia while debe tener la siguiente forma:
while (condicion) {
sentencias;
}
Una sentencia while vaca debe tener la siguiente forma
while (condicion);

7.7 Sentencias do-while

una sentencia do-while debe tener la siguiente forma:
do {
sentencias;
} while (condicion);

7.8 Sentencias switch

Una sentencia switch debe tener la siguiente forma:
switch (condicion) {
case ABC:
sentencias;
/* cae al siguiente */
case DEF:
sentencias;
break;
case XYZ:
sentencias;
break;
default:
sentencias;
break;
Cada vez que un case cae al siguiente, osea se produce una cascada (esto es porque no incluye la sentencia break), se
agrega un comentario donde la sentencia break debera ir. Esto quedo demostrado en el ejemplo anterior con el
comentario :
/* cae al siguiente */
Toda sentencia switch debe incluir un caso por defecto (default). El break en el caso por defecto es redundante, pero
previene un error de cascada si se agrega otro caso.

7.9 Sentencias try-catch

Una sentencia try-catch deben ser de la siguiente forma:
try {
sentencias;
} catch (ClaseExcepcion e) {
sentencias;
}

una sentencia try-catch tambin puede estar seguida de un finally, el cual se ejecuta independientemente de si el
bloque try se complet o no con xito.
try {
sentencias;
}catch (ClaseExcepcion e) {
sentencias;
} finally {
sentencias;
}

8. Espacios en blanco
8.1 Lneas en blanco
La lneas en blanco mejoran la legibilidad estableciendo secciones de cdigo que estn relacionadas lgicamente.
Dos lneas en blanco deben usarse siempre en las siguientes circunstancias:

Entre secciones de un archivo fuente.

Entre definiciones de clase e interfaz.

Una lnea en blanco debe usarse siempre en las siguientes circunstancias:

Entre mtodos
Entre las variables locales en un mtodo y su primer sentencia.
Antes de un comentario en bloque (vea la seccin 5.1.1) o uno simple (vea la seccin 5.1.2)
Entre secciones lgicas dentro del mtodo para mejorar la legibilidad.

8.2 Espacios en blanco

Los espacios en blanco deben usarse en las siguiente circunstancias:

Una palabra clave seguida de un parntesis deben estar separados por un espacio:

while

(true)

{
...

}
Nota: El espacio en blanco no debe usarse entre el nombre de un mtodo y su parntesis de apertura. Esto ayuda
distinguir las llamadas a los mtodos de las palabras clave.

Un espacio en blanco debe aparecer despus de las comas en las listas de argumentos.
Todos los operadores binarios excepto "." deben estar separados de sus operandos por espacios. Los espacios en
blanco nunca deben separar operadores unitarios como el menos unitario, incremento(++) y decremento(--), de
sus operandos:

a += c + d;
a = (a + b) / (c * d);
while (d++ = s++) {
n++;
}
prints("size is " + foo + "\n");

Las expresiones en una sentencia for deben estar separadas por espacios en blanco.

for (expr1; expr2; expr3)

Las mutaciones deben estar seguidas de un espacio en blanco.

miMetodo((byte) aNum, (Object) x);

miMetodo((int) (cp + 5), ((int) (i + 3)) + 1

9. Convenciones sobre los nombres

Las convenciones sobre los nombre hacen al programa mas entendible hacindolo fcil de leer. Tambin pueden dar
informacin acerca de la funcin del identificador - por ejemplo, si este es una constante, un paquete o una clase - lo
cul puede ser de utilidad para entender el cdigo.

Tipo de identificador

Reglas de nombre

Ejemplos

El prefijo de un nombre de paquete nico se com.sun.eng

escribe siempre todo en minsculas (cdigo
ASCII) y debe ser uno de los nombres de com.apple.quicktime.v2
dominio de alto nivel, actualmente com, edu,
gov, mil, net, org o uno de los cdigos ingleses edu.cmu.cs.bovik.cheese
de dos letras para identificar pases como estn
especificados en las normas ISO 3166 y 1981.
Paquetes
Los componentes subsecuentes del nombre de
un paquete varan de acuerdo a unas
convenciones de nombre internas propias del la
organizacin. Tales convenciones pueden
especificar que ciertos componentes de nombres
de directorio seas divisin, departamento,
proyecto, mquina, o cuentas de acceso.

Clases

Interfaces

Mtodos

Variables

Constantes

Los tipos de nombres de clase deben ser

sustantivos, de mezclando la primera letra de
cada palabra interna en mayscula. Trate de
mantener sus nombres de clase simples y
descriptivos. Use palabras enteres - evite usar
acrnimos y abreviaciones (a menos que la
abreviacin sea mucho ms usada que la forma
larga como URL o HTML)

class Raster

Las interfaces deben nombrarse como las clases

interface RasterDelegate
interface Storing

Los mtodos deben ser verbos, mezclando la

primera letra en minscula , la la primera letra
de cada palabra interna en mayscula

run();
runFast();
getBackground();

Excepto para las variables, toda instancia, clase

y constante de clase mezclan minsculas en la
primera letra y las palabras internas comienzan
con maysculas. Los nombre de las variables no
deben empezar con "_" o "$" an cuando
ambos signos estn permitidos.

int
char
float myWidth;

i;
c;

static
final
MIN_WIDTH
=

int
4;

class ImageSprite

Los nombre de las variables deben ser cortos y

pesar de eso significativos. La eleccin para un
nombre de variable debe ser un mnemnico esto es, que est diseada para indicar a un
observador casual el objetivo de uso. Las
variables de un caracter deben evitarse excepto
para variables temporales que se desecharn. i,
j, k, m y n son nombres comunes para variables
temporales enteras, c, d y e para los caracteres
Los nombres de las variables declaradas como
constantes y de constantes ANSI deben estar
todas en maysculas con palabras separadas por
"_" (las constantes ANSI deben evitarse para
una fcil depuracin).

static
final
MAX_WIDTH =
static
final
GET_THE_CPU = 1;

int
999;
int

10. Prcticas de programacin

10.1 Proveer Acceso a variables de instancia y clase
No haga pblica ninguna variable de instancia o variable de clase, a menos que tenga una buena razn. Con frecuencia,
las instancias no necesitan establecerse o darse explcitamente-muchas veces esto sucede como un efecto secundario de
las llamadas a mtodos.
Un ejemplo apropiado de variables de instancia pblicas es el cual la clase es esencialmente una estructura de datos sin
comportamiento. En otras palabras, si usramos struct en lugar de class (si Java soportara struct), entonces es
conveniente hacer pblicas las variables de instancia de la clase

10.2 Referenciar variables de clase y mtodos

Evite usar un objeto para acceder a una variable o mtodo esttico. Use el nombre de la clase en su lugar. Por ejemplo:
classMethod(); // bien
AClass.classMethod; // bien
unObjeto.classMethod; //EVITELO!

10.3 Constantes
Las constantes numricas (literales) no deben codificarse directamente, excepto para -1, 0 y 1, las que pueden aparecer
en un bucle for como valores de conteo

10.4 Asignacin de variables

Evite asignar muchas variables con el mismo valor en una sola sentencia, porque es difcil de leer, ejemplo:
fooBar.fChar = barFoo.lchar = 'c'; // EVITELO!
No use el operador de asignacin en un lugar donde este pueda ser confundido con un operador de igualdad. Ejemplo:

if (c++ = d++) { // EVITELO! (Java lo prohibe)

...
}
Debe escribirse como:
if ((c++ = d++) != 0) {
...
}
No use asignaciones incrustadas en un intento de mejorar el rendimiento en tiempo de ejecucin. Este es trabajo del
compilador. Ejemplo:

d = (a = b + c) + r; // EVITELO!
Debe escribirse como:
a = b + c;
d = a + r;

10.5 Prcticas diversas

10.5.1 Parntesis
Es una buena idea usar generosamente los parntesis en expresiones que involucren mezclas de operadores para evitar
problemas de precedencia de operadores. Aun si la precedencia de operadores le parece clara, no significa que tambin
lo sea para otros programadores - no debemos asumir que otros programadores conocen la precedencia tan bien como
nosotros.
if (a == b && c == d) // EVITELO!
if ((a == b) && (c == d)) // USELO

10.5.2 Retorno de valores

Trate de hacer la estructura de sus programas corresponda al objetivo. Ejemplo:
if (booleanExpresion) {
return true;
} else {
return false;
}
En lugar de esto debe ser:
return booleanExpresion;
De manera similar
if (condicion) {
return x;
}
return y;
Debe ser:
return (condicion ? x

y);

10.5.3 Expresiones antes del operador condicional "?"

Si una expresin conteniendo un operador binario aparece entes del "?" en la terna de operadores "? :" debe estar entre
parntesis. Ejemplo:
(x >= 0) ? x : -x;

10.5.4 Comentarios especiales

Use XXX en un comentario para indicar algo que esta mal pero trabaja. Use FIXME para indicar algo que esta mal y no
trabaja.

11. Ejemplos de cdigo

11.1 Ejemplo de cdigo fuente Java
El siguiente ejemplo muestra como darle formato a un archivo fuente Java conteniendo una clase pblica simple. Las
interfaces se formatean de manera similar. Para ms informacin, vea "Declaraciones Clases e interfaces" en el punto
3.1.3 y "Comentarios de documentacion" en el punto 5.2

/*
* @(#)Blah.java 1.82 99/03/18
*
* Copyright (c) 1994-1999 Sun Microsystems, Inc.
* 901 San Antonio Road, Palo Alto, California, 94303, U.S.A.
* All Rights Reserved.
*
* This software is the confidential and proprietary information of Sun
* Microsystems, Inc. ("Confidential Information"). You shall not
* disclose such Confidential Information and shall use it only in
* accordance with the terms of the license agreement you entered into
* with Sun.
*/
package java.blah;
import java.blah.blahdy.BlahBlah;
/**
* La descripcion de la clase viene aqui
*
* @version 1.82 18 Mar 1999
* @author Firstname Lastname
*/
public class Blah extends SomeClass {
/* Un comentario de implementacion de clase va aqui */
/** comentario de documentacion para classVar1 */
public static int classVar1;
/**
* Comentario de documentacion para classVar2
* que tiene mas de una linea
*/
private static Object classVar2;
/** comentario de documentacion para instanceVar1 */
public Object instanceVar1;

/** comentario de documentacion para instanceVar2 */

protected int instanceVar2;
/** comentario de documentacion para instanceVar3 */
private Object[] instanceVar3;
/**
* ...comentario de documentacion para el constructor Blah...
*/
public Blah() {
// ... la implementacion va aqui ...
}
/**
* ...comentario de documentacion para el metodo doSomething...
*/
public void doSomething() {
// ...la implementacion va aqui...
}
/**
* ...comentario de documentacion para el mtodo doSomethingElse ...
* @param someParam y su descripcion
*/
public void doSomethingElse(Object someParam) {
// ...la implementacion va aqui...
}
}