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

1 Comentario de documentacin de la clase o interfaz. (/** ... */)

Vea "Comentarios de documentacin" en la seccin 5.2.

2 Sentencia class o interface

3 Comentario de implementacin de la clase o interfaz (/*...*/) si es necesario.

Este comentario debe tener cualquier informacin complementaria de la clase o interfaz que no sea apropiada para el comentario de documentacin.

4 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).

5 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).

6 Constructores

7 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 level; // nivel de identacin int size; // tamao de la tabla Object 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

Paquetes

El prefijo de un nombre de paquete nico se escribe siempre todo en minsculas (cdigo ASCII) y debe ser uno de los nombres de dominio de alto nivel, actualmente com, edu, gov, mil, net, org o uno de los cdigos ingleses de dos letras para identificar pases como estn

especificados en las normas ISO 3166 y 1981.

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.

com.sun.eng

com.apple.quicktime.v2

edu.cmu.cs.bovik.cheese

Clases

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

class ImageSprite

Interfaces Las interfaces deben nombrarse como las clases interface RasterDelegate

interface Storing

Mtodos Los mtodos deben ser verbos, mezclando la primera letra en minscula , la la primera letra de cada palabra interna en mayscula

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

Variables

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.

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

int i; char c; float myWidth;

Constantes

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 int

MIN_WIDTH = 4; static final int MAX_WIDTH = 999; static final int GET_THE_CPU = 1;

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... } }