Convenciones de código Java

1 - Introducción
1.1 Por qué convenios tienen código
Las convenciones de código son importantes para los programadores por una serie de razones:
• 80% del costo de vida útil de una pieza de software va a mantenimiento.
• Casi ningún software se mantiene durante toda su vida por el autor original.
• Las convenciones de código mejoran la legibilidad del software, permitiendo a los ingenieros
entender el nuevo código con mayor rapidez y en profundidad.
• Si envía su código fuente como un producto, es necesario asegurarse de que esté tan bien empaquetado
y limpio como cualquier otro producto que usted cree.
1.2 Reconocimientos
Este documento refleja los estándares de codificación del lenguaje Java que se presentan en el Lenguaje Java
Especificación, de Sun Microsystems. Las principales contribuciones son de Peter King, Patrick
Naughton, Mike Demoney, Jonni Kanerva, Kathy Walrath, y Scott Hommel.
Para preguntas referentes a la adaptación, modificación o redistribución de este documento, por favor
lea nuestro aviso de derechos de autor en http://java.sun.com/docs/codeconv/html/Copyright.doc.html.
Los comentarios sobre este documento deben ser enviados a nuestro formulario de comentarios en
http://java.sun.com/ docs / forms / sendusmail.html.

2 - Nombres de archivo
Esta sección lista los sufijos de uso común de archivos y nombres.
2.1 Sufijos de archivo
JavaSoft utiliza los siguientes sufijos de archivo:
File Type (Tipo de archivo) Suffix (Sufijo)
Java source .java
Java bytecode .class
2.2Nombres de archivos comunes
Los nombres de los archivos de uso frecuente incluyen
Nombre de archivo(File Name) Uso
GNUmakefile El nombre preferido para makefiles.
Utilizamos gnumake construir nuestro software.

README El nombre preferido para el archivo que resume el

contenido de un directorio en particular.

3. Organización de archivos
Un archivo se compone de secciones que deben ser separados por líneas en blanco y un comentario opcional
la identificación de cada sección.
Archivos de más de 2000 líneas son engorrosos y deben evitarse.
Para un ejemplo de un programa en Java con el formato correcto, consulte "Fuente Java Ejemplo de archivo"
en la página 19.
3.1 Java Source Files
Cada archivo fuente Java contiene una sola clase pública (public class) o interfaz. Cuando las clases privadas
e interfaces están asociadas con una clase pública, puede poner en el mismo archivo de origen como la public
class. La clase pública (public class) debe ser la primera clase o interfaz en el archivo.
Archivos fuente de Java tiene el siguiente orden:
• A partir de observaciones (véase "Empezando Comentarios" en la página 4)
• Paquete y las declaraciones de importación; por ejemplo:

• Declaraciones de clase y de interfaz (consulte "clase e interfaz Declaraciones" en la página 4)

3.1.1 Empezando Comentarios
Todos los archivos de origen deben comenzar con un comentario de c-style que enumera el programador (s),
la fecha, un aviso de copyright, y también una breve descripción de la finalidad del programa. Por ejemplo:
/*
* Classname
*
* Version info
*
* Copyright notice
*/
3.1.2 Paquete de declaración e importación.
La primera línea que no sea la mayoría de los comentarios de los archivos de código fuente de Java es una
sentencia de paquete. Después de eso,
declaraciones de importación pueden seguir. Por ejemplo:

3.1.3 Clase e Interface Declaraciones

En la siguiente tabla se describen las partes de una declaración de clase o interfaz, en el orden en que
debería aparecer. Consulte "Fuente Java Ejemplo de archivo" en la página 19 para ver un ejemplo que incluye

comentarios.
Part of Class/Interface Declaration Notes
1| Class/interface documentation Consulte la sección "información sobre lo que debe
comment (/**...*/) ser una documentación de comentarios".
2| Class or interface declaración
3| Class/interface implementation Este comentario debería contener cualquier clase de
comment (/*...*/), if necessary información de toda la interfaz que no era apropiado
para el comentario de documentación de clase /
interfaz.
4| Clase (static) variable Primero las variables de clase public , luego las
protected, y luego las private.
5| Variables de instancia Primero public, entonces protected, y luego private.
6 |Constructors
7 | Metodos Estos métodos deben ser agrupados por
funcionalidad en lugar de por el alcance o la
accesibilidad. Por ejemplo, un método de clase
privada puede estar en entre dos métodos de
instancia pública. El objetivo es para hacer de la
lectura y la comprensión del código sea más fácil.

4. sangría
Cuatro espacios se deben utilizar como la unidad de sangría. La construcción exacta de la sangría
(espacios vs pestañas) es indeterminado. Aquí se deben establecer exactamente cada 8 espacios (no 4).
4.1 Longitud de la línea
Evite líneas de más de 80 caracteres, ya que no son bien manejados por muchos terminales y
herramientas.
Nota: Ejemplos para el uso en la documentación deben tener una línea más corta longitud-generalmente no
más de 70 caracteres.
4.2 Líneas de embalaje
Cuando una expresión no cabe en una sola línea, romperlo de acuerdo con estos principios generales:
• Romper después de una coma.
• Romper antes un operador.
• Prefiera las pausas de más alto nivel para bajar a nivel de los descansos.
• Alinear la nueva línea con el principio de la expresión en el mismo nivel en el anterior linea.
• Si las reglas anteriores llevan a código confuso o código que se aplastó contra el derecho
margen, a sólo 8 espacios en lugar de sangría.
Estos son algunos ejemplos de romper las llamadas a métodos:

A continuación se presentan dos ejemplos romper de una expresión aritmética. El primero es el preferido, ya
que la ruptura se produce fuera de la expresión entre paréntesis, que está en un nivel superior.

A continuación se presentan dos ejemplos de sangría declaraciones de métodos. El primero es el caso

convencional. El segundo se desplazaría la segunda y tercera líneas a la derecha si se utiliza convencional
sangría, así que en lugar que sangra sólo 8 espacios.

Ajuste de las líneas de sentencias si generalmente deben usar la regla de 8-espacio, convencional (4 espacio)
sangría (identation) hace difícil ver el cuerpo. Por ejemplo:
Aquí hay tres maneras aceptables para formatear expresiones ternarias:

5. Comentarios
Los programas Java pueden tener dos tipos de comentarios: comentarios de implementación y
comentarios de documentación. Los comentarios de implementación son las que se encuentran en C + +, que
son delimitados por / * ... * / y / /.
Los comentarios de documentación (conocidos como "los comentarios de doc") son -Sólo de Java, y están
delimitados por / ** ... * /. Los comentarios de documentación se pueden extraer a los archivos HTML
utilizando la herramienta javadoc.
Los comentarios de implementación son para comentar fuera de código o los comentarios acerca de la en
particular aplicación. Los comentarios de documentación están destinados a describir la especificación del
código, desde el punto de vista de la implementación libre para ser leído por los desarrolladores que podrían
no necesariamente tener el código fuente a la mano.
Los comentarios deben ser usados para dar una visión general de código y proporcionar información adicional
que es no está fácilmente disponible en el propio código. Los comentarios deben contener sólo la información
que es relevante para la lectura y la comprensión del programa. Por ejemplo, información acerca de cómo el
paquete correspondiente se construye o en qué directorio reside no debe incluirse como comentar.
La discusión de las decisiones de diseño no triviales o no obvias es apropiado, pero evitar la duplicación de
información que está presente en (y claro a partir de) el código es demasiado fácil para los comentarios
redundantes para salir de la fecha. En general, evite cualquier comentario que pueda salir de la fecha que el
código evoluciona.
Nota: La frecuencia de los comentarios a veces refleja la pobre calidad del código. Cuando usted se siente
obligado a añadir un comentario, considere volver a escribir el código para hacerlo más claro.
Los comentarios no deben ser encerrados en grandes cajas dibujadas con asteriscos u otros caracteres. Los
comentarios nunca deben incluir caracteres especiales como el de avance y retroceso.

5.1 Formatos para la Implementación de Comentarios

Los programas pueden tener cuatro estilos de comentarios de implementación: bloque, de una sola línea, de
arrastre y de final de línea.
5.1.1 Bloque de comentarios
Los bloques de comentarios se utilizan para proporcionar descripciones de ficheros, métodos, estructuras de
datos y algoritmos. Los bloques de comentarios deben utilizarse al principio de cada archivo y antes de cada
método. También se pueden utilizar en otros lugares, tales como dentro de los métodos. Los bloques de
comentarios dentro de una función o método deben tener una sangría al mismo nivel que el código que
describen.
Un bloque de comentarios debe ser precedido por una línea en blanco para diferenciarse del resto del código.
Los bloques de comentarios tienen un asterisco "*" al principio de cada línea, excepto la primera.
/*
* Here is a block comment.
*/

Los bloques de comentarios pueden comenzar con / * -, que es reconocido por guión (1) como el comienzo de
un bloque de comentario que no debe reformateado. Ejemplo:

/*
* Here is a block comment with some very special
* formatting that I want indent (1) to ignore.
*
* one
* two
* three
*/

Nota: Si usted no usa guión (1), usted no tiene que usar / * - en el código o hacer otras concesiones a la
posibilidad de que alguien más podría correr guión (1) en su código.
Véase también "Comentarios de documentación" en la página 9.
5.1.2 Comentarios de una sola línea
Los comentarios cortos pueden aparecer en una sola línea con sangría al nivel del código que sigue. Si un
comentario no se puede escribir en una sola línea, se debe seguir el formato de bloque de comentarios (ver
sección 5.1.1). Un comentario de una sola línea debe ser precedida por una línea en blanco. He aquí un
ejemplo de comentario de una sola línea en el código Java (ver también "Comentarios de documentación" en
la página 9):

if (condition) {
/* Handle the condition. */
...
}

5.1.3 Comentarios de arrastre

Los comentarios muy cortos pueden aparecer en la misma línea que el código que describen, pero se deben
cambiar lo suficiente como para separarlos de las declaraciones. Si más de un comentario breve aparece en un
fragmento de código, todos ellos deben tener una sangría a la misma configuración de la ficha. Evite el estilo
lenguaje ensamblador de comentar cada línea de código ejecutable con un comentario final.
He aquí un ejemplo de un comentario final en el código de Java (ver también "Comentarios de
documentación" en la página 9):

if (a == 2) {
return TRUE; /* special case */
} else {
return isprime(a); /* works only for odd a */
}

5.1.4 Comentarios de final de línea

El delimitador de comentario (//) comienza un comentario que sigue la nueva línea. También puede hacer
observaciones a una línea completa o sólo una línea parcial. No debe ser utilizado en varias líneas
consecutivas para comentarios de texto; sin embargo, puede ser utilizado en múltiples líneas consecutivas
para comentar secciones de código. Ejemplos de los tres estilos siguen:

if (foo > 1) {
// Do a double-flip.
...
}
else
return false; // Explain why here.

//if (bar > 1) {

//
// // Do a triple-flip.
// ...
//}
//else
// return false;

5.2 Comentarios de documentation

Nota: Consulte "Fuente Java Ejemplo de archivo" en la página 19 para ver ejemplos de los formatos de
comentarios que aquí se describen.
Para más detalles, consulte "Cómo escribir Doc Comentarios para Javadoc", que incluye información sobre
las etiquetas doc comentario (@return, @param, @see):

http://java.sun.com/products/jdk/javadoc/writingdoccomments.html

Para más detalles sobre Los comentarios Doc y javadoc, consulte la página principal javadoc en:

http://java.sun.com/products/jdk/javadoc/

Los comentarios de documentación describen las clases de Java, interfaces, constructores, métodos y campos.
Cada comentario doc se establece dentro de los delimitadores de comentarios / ** ... * /, con un comentario
por API. Este comentario debe aparecer justo antes de la declaración:

/**
* The Example class provides ...
*/
class Example { ...

Tenga en cuenta que las clases y las interfaces no se les aplican sangría, mientras que a sus miembros si se les
aplican. La primera línea del comentario doc (/ **) para las clases y las interfaces no se sangra; las siguientes
líneas de comentarios doc disponen de 1 plaza de sangría (para alinear verticalmente los asteriscos). Los
miembros, incluidos los constructores, tienen 4 espacios para la primera línea de comentario doc y 5 espacios
a partir de entonces.
Si usted necesita dar información sobre una clase, interfaz, una variable o método que no es apropiada para la
documentación, utilice la aplicación de un bloque de comentario (ver sección 5.1.1) o de una sola línea (véase
la sección 5.1.2) inmediatamente después la declaración. Por ejemplo, los detalles sobre la implementación de
una clase deben ir en un bloque de comentarios a raíz de la declaración de clase, no en el comentario clase
doc.

Los comentarios de documentación no deben colocarse dentro de un bloque de método o definición de

constructor, porque Java asocia los comentarios de documentación con la primera declaración después del
comentario.

6- Declaraciones

6.1 Numero por línea

Se recomienda una declaración por línea, ya que anima a comentar. En otras palabras,

int level; // indentation level

int size; // size of table

Se prefiere más

int level, size;

En ningún caso deberían ser declaradas las variables y funciones en la misma línea. Ejemplo:

long dbaddr, getDbaddr(); // WRONG!

No coloque diferentes tipos en la misma línea. Ejemplo:

int foo, fooarray[]; //WRONG!

Nota: Los ejemplos anteriores usan un espacio entre el tipo y el identificador. Otra alternativa aceptable es el
uso de pestañas, por ejemplo:

int level; // indentation level

int size; // size of table
Object currentEntry; // currently selected table entry

6.2 Colocación

Ponga declaraciones sólo al comienzo de los bloques. (Un bloque es cualquier código rodeado por llaves "{" y
"}") No espere para declarar variables hasta su primer uso; puede confundir el programador desprevenido y
obstaculizar la portabilidad del código dentro del alcance.

void MyMethod() {
int int1; // beginning of method block

if (condition) {
int int2; // beginning of "if" block
...
}
}

La única excepción a la regla son índices de bucles para, que en Java se pueden declarar en la sentencia para:

for (int i = 0; i < maxLoops; i++) { ...

Evitar declaraciones locales que oculten declaraciones en los niveles superiores. Por ejemplo, no declare el
mismo nombre de variable en un bloque interno:

int count;
...
func() {
if (condition) {
int count; // AVOID!
...
}
...
}

6.3 Inicializacion

Trate de inicializar las variables locales donde están declaradas. La única razón para no inicializar una
variable donde se declara es si el valor inicial depende de algún cálculo ocurra primero.

6.4 Clase e interfaz de declaraciones

Al codificar clases e interfaces Java, las siguientes reglas de formato se deben seguir:
• No hay espacio entre el nombre del método y el paréntesis "(" a partir de su lista de parámetros
• llave de apertura "{" aparece al final de la misma línea que la instrucción de declaración
• llave de cierre "}" se inicia una línea propia con sangría para que coincida con su abertura correspondiente
declaración, excepto cuando se trata de una sentencia nula la "}" debe aparecer inmediatamente después de la
"{".

class Sample extends Object {

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

• Los métodos están separados por una línea en blanco.

7 – Sentencia
____________________________________________________________
7.1 Simple Sentencia

Cada línea debe contener como mucho un comando. Ejemplo:

No utilice el operador coma para agrupar varios estados a menos que sea por una razón obvia.
Ejemplo:
7.2 Compound Sentencia

Compound statements son declaraciones que contienen listas de instrucciones entre llaves
“{ statements }”. Consulte las siguientes secciones para obtener ejemplos.

• Las sentencias encerradas deben tener una sangría un nivel más que la sentencia compuesta.

• La llave de apertura debe estar al final de la línea que comienza la sentencia compuesta; la llave
de cierre debe comenzar una línea y tener una sangría al principio de la sentencia compuesta.

• Los apoyos se utilizan alrededor de todos los estados, incluso los únicos, cuando forman parte de
una estructura de control, como as a if-else or for comandos. Esto hace que sea más fácil para
agregar declaraciones sin introducir accidentalmente errores debido a olvidarse de agregar las
llaves.

7.3 return Sentencia

Un return statement con un valor no deben usar paréntesis a menos que hagan el valor de retorno
más obvia de alguna manera. Ejemplo:

7.4 if, if-else, if-else-if-else Sentencia

El if-else clase de enunciados debe tener la siguiente forma:

Nota: si las declaraciones siempre usan llaves {}. Evite lo siguiente error-prone de:
7.5 for Sentencia

A for statement debe tener la siguiente forma:

Un vacío de declaración (una en la que todo el trabajo se realiza en la inicialización, condición, y las
cláusulas de actualización) debe tener la siguiente forma:

Cuando se utiliza el operador de coma en la inicialización o actualización de la cláusula de un for

Statements, evitar la complejidad de utilizar más de tres variables. Si es necesario, usar
declaraciones separadas antes de que el bucle (para la cláusula de inicialización) o al final del bucle
(para la cláusula de actualización).

7.6 while Sentencia

A while statement debe tener la siguiente forma:

Un vacío while statement debe tener la siguiente forma:

7.7 do-while Sentencia

A do-while statement debe tener la siguiente forma:

7.8 switch Sentencia

A switch statement debe tener la siguiente forma:

Cada vez que pasa al siguiente caso (no incluye una sentencia break), añadir un comentario donde
la sentencia break normalmente sería. Esto se muestra en el ejemplo de código anterior con el / *
cae a través * / comment.

Cada sentencia switch debe incluir un caso predeterminado. El avance en el caso por defecto es
redundante, pero impide que un error de paso si se añade posteriormente otro caso.

7.9 try-catch Sentencia

A try-catch statement debe tener la siguiente forma:

8 – Espacio en blanco-
____________________________________________________________
8.1 Lineas en blanco

Las líneas en blanco mejoran la legibilidad mediante la activación de las secciones de código que se
relacionan lógicamente.

Dos líneas en blanco siempre se deben utilizar en las siguientes circunstancias:

• Entre las secciones de un archivo de origen

• Entre las definiciones de clases e interfaces

Una línea en blanco siempre se debe utilizar en las siguientes circunstancias:

• Entre los métodos •

Entre las variables locales en un método y su primera declaración
• Antes de un bloque (véase la sección 5.1.1) o de una sola línea (véase la sección 5.1.2)
comentario
• Entre secciones lógicas dentro de un método para mejorar la legibilidad

8.2 Espacios en blanco

Los espacios en blanco deben ser utilizados en las siguientes circunstancias:

• Una palabra clave seguida de un paréntesis debe estar separado por un espacio. Ejemplo:

Tenga en cuenta que un espacio en blanco no se debe utilizar entre un nombre de método y su
paréntesis de apertura. Esto ayuda a distinguir las palabras clave de las llamadas a métodos.

• Un espacio en blanco debe aparecer después de las comas en las listas de argumentos.
• Todos los operadores binarios, salvo. deben ser separados de sus operandos por espacios. Los
espacios en blanco no deben separar los operadores unarios como menos unario, incremento ("+
+"), y decremento ("-") de sus operandos. Ejemplo:

• Las expresiones en una sentencia for deben estar separados por espacios en blanco. Ejemplo:

• El yeso debe ser seguido por un espacio en blanco. Ejemplos:

9 - Convenciones de nomenclatura
____________________________________________________________
Convenciones de nombres hacen que los programas sean más comprensibles, haciendo que sean
más fáciles de leer. También pueden dar información acerca de la función del ejemplo
identificador-por ejemplo, si se trata de una constante, paquete o una clase, lo cual puede ser útil
para entender el código.

Los convenios que figuran en esta sección son de alto nivel. Otros convenios se dan en (a
determinar).
Identifier
Rules for Naming Examples
Type
Classes Los nombres de clase deben ser class Raster;
sustantivos, en mayúsculas y class
minúsculas con la primera letra de ImageSprite;
cada palabra interna en mayúsculas.
Trate de mantener sus nombres de
clase simples y descriptivos. Use
palabras enteras-evitar las siglas y
abreviaturas (a menos que la
abreviatura es mucho más
ampliamente utilizado de la forma
larga, como la dirección URL o HTML).
Interfaces Nombres de interfaz se deben interface
capitalizar como nombres de clase. RasterDelegate;
interface Storing;
Methods Los métodos deben ser verbos, en run();
mayúsculas y minúsculas con la primera runFast();
letra en minúscula, con la primera letra getBackground()
de cada palabra interna en mayúsculas. ;

Variables A excepción de las variables, todas las int i;

constantes de instancia, de clase y de char *cp;
clase son en mayúsculas y minúsculas, float
con una primera letra minúscula. myWidth;
Palabras internas comienzan con letras
mayúsculas.

Constants Los nombres de variables deben ser int MIN_WIDTH = 4;

cortas pero significativo. La elección de int MAX_WIDTH =
un nombre de variable debe ser-que es 999; int
mnemónico, diseñado para indicar al GET_THE_CPU = 1;
observador casual la intención de su
uso. Nombres de variable de un solo
carácter se debe evitar excepto para las
variables temporales "usar y tirar". Los
nombres comunes de las variables
temporales son i, j, k, m, yn para
enteros; c, d, ye para los personajes.

10 - Prácticas de programación
____________________________________________________________
10.1 Proporcionar acceso a la instancia y de clase Variables
No haga ningún caso ni public class variable sin una buena razón. A menudo, las variables de
instancia no es necesario establecer o conseguido-a menudo lo que sucede como un efecto
secundario de las llamadas a métodos de forma explícita.

Un ejemplo de variables de instancia pública apropiados es el caso en el que la clase es

esencialmente una estructura de datos, sin comportamiento. En otras palabras, si usted ha
utilizado una estructura en lugar de una clase (si Java soportado struct), entonces es conveniente
poner a las variables de instancia de la clase pública.

10.2 En referencia a las variables de clase y métodos

Evite el uso de un objeto para tener acceso a una clase de variable o método (estático). Utilice un
nombre de clase en lugar. Por ejemplo:

10.3 Constantes

Constantes numéricas (literales) no deben ser codificados directamente, a excepción de -1, 0 y 1,

que puede aparecer en un bucle for como valores de contador.

10.4 Las asignaciones de variables

Evite asignar varias variables con el mismo valor en una sola sentencia. Es difícil de leer. Ejemplo:

No utilizar el operador de asignación en un lugar donde puede ser fácilmente confundido con el
operador de igualdad. Ejemplo:

Debe ser escrito como

No utilice asignaciones incluidas en un intento de mejorar el rendimiento en tiempo de ejecución.

Este es el trabajo del compilador, y además, es raro que en realidad ayuda. Ejemplo:

Debe ser escrito como

10.5 Prácticas Varias

10.5.1 Parentesis

Por lo general, es una buena idea usar paréntesis liberalmente en expresiones con operadores
mixtos para evitar problemas de precedencia del operador. Aunque la prioridad de los operadores
parece claro que, tal vez no sea para los demás-que no debe asumir que otros programadores
saben prioridad, así como usted lo hace.

10.5.2 Devolver valores

Trate de que la estructura de su programa coincide con la intención. Ejemplo:

lugar debe ser escrito como

Del mismo modo,

debe ser escrito como

10.5.3 Expresiones antes ‘?’ en los operadores condicionales

Si aparece una expresión que contiene un operador binario antes de la ? en el ternario ? :

Operador, debe ser entre paréntesis. Ejemplo:

10.5.4 Comentarios especiales

Utilice XXX en un comentario a la bandera de algo que es falso, pero funciona. Utilice ARREGLAME
marcar algo que es falso y roto.
11 - Ejemplos de código
____________________________________________________________
11.1 Fuente Java Ejemplo de archivo

El siguiente ejemplo muestra cómo dar formato a un archivo fuente Java que contiene una sola
clase pública. Las interfaces se formatean de manera similar. Para obtener más información,
consulte "clase e interfaz Declaraciones" en la página 4 y "Comentarios de documentación" en la
página 9