Convenciones de Código para el lenguaje de programación
JAVA™
Revisado 20 Abril de 1999
por Scott Hommel
Sun Microsystems Inc.
Traducido al castellano 10 Mayo del 2001
por Alberto Molpeceres
http://www.javahispano.com
Convenciones de Código Java
Conveciones de código para el lenguaje de programación
Java TM
Revisado, 20 de Abril de 1999
Traducido al castellano, 10 de Mayo del 2001
1 Introducción
1.1 Por qué tener convenciones de código
1.2 Reconocimientos
1.3 Sobre la traducción
2 Nombres de ficheros
2.1 Extensiones de los ficheros
2.2 Nombres de ficheros comúnes
3 Organización de los ficheros
3.1 Ficheros fuente Java
3.1.1 Comentarios de comienzo
3.1.2 Sentencias package e import
3.1.3 Declaraciones de clases e interfaces
4 Indentación
4.1 Longitud de la línea
4.2 Rompiendo lineas
5 Comentarios
5.1 Formato de los comentarios de implementación
5.1.1 Comentarios de bloque
5.1.2 Comentarios de una línea
5.1.3 Comentarios de remolque
5.1.4 Comentarios de fin de linea
5.2 Comentarios de documentación
6 Declaraciones
6.1 Cantidad por línea
6.2 Inicialización
6.3 Colocación
6.4 Declaraciones de clase e interfaces
7 Sentencias
7.1 Sentencias simples
7.2 Sentencias compuestas
7.3 Sentencias de retorno
7.4 Sentencias if, if-else, if else-if else
7.5 Sentencias for
5
5
5
5
6
6
6
7
7
7
7
7
9
9
9
12
12
13
13
13
13
14
15
15
15
15
16
17
17
17
17
17
18
3
Convenciones de Código Java
7.6 Sentencias while
7.7 Sentencias do-while
7.8 Sentencias switch
7.9 Sentencias try-catch
8 Espacios en blanco
8.1 Líneas en blanco
8.2 Espacios en blanco
9 Convenciones de nombres
10 Hábitos de programación
10.1 Proporcionando acceso a variables de instancia y de clase
10.2 Referencias a variables y métodos de clase
10.3 Constantes
10.4 Asignaciones de variables
10.5 Hábitos varios
10.5.1 Paréntesis
10.5.2 Valores de retorno
10.5.3 Expresiones antes de ‘?’ en el operador condicional
10.5.4 Comentarios especiales
11 Ejemplos de código
11.1 Ejemplo de fichero fuente Java
18
18
18
19
20
20
20
22
24
24
24
24
24
24
24
25
25
25
26
26
4
Convenciones de Código Java
Convenciones de código para el lenguaje de
programación JavaTM
1 - Introducción
1.1 Por qué convenciones de código
Las convenciones de código son importantes para los programadores por un gran número de
razones:
• El 80% del coste del código de un programa va a su mantenimiento.
• Casi ningún software lo mantiene toda su vida el auto original.
• Las convenciones de código mejoran la lectura del software, permitiendo entender
código nuevo mucho más rapidamente y más a fondo.
• Si distribuyes tu código fuente como un producto, necesitas asegurarte de que esta
bien hecho y presentado como cualquier otro producto.
Para que funcionen las convenciones, cada persona que escribe software debe seguir la
convención. Todos.
1.2 Agradecimientos
Este documento refleja los estandares de codificación del lenguaje Java presentados en Java
Language Specification , de Sun Microsystems, Inc. Los mayores contribuidores son Peter
King, Patrick Naughton, Mike DeMoney, Jonni Kanerva, Kathy Walrath, y Scott Hommel.
Este documento es mantenido por Scott Hommel. Enviar los comentarios a
[email protected]
1.3 Sobre la traducción
Este documento ha sido traducido al español por Alberto Molpeceres, para el sitio web
javaHispano (www.javaHispano.com), y se encuentra ligado al objetivo de dicha web para
fomentar el uso y conocimiento del lenguaje Java dentro del mundo hispano-hablante.
Se ha intentado hacer una traducción lo más literal posible, y esta es la única parte del
documento que no pertenece a la versión original.
Se pueden enviar los comentarios sobre la traducción a la dirección:
[email protected]
5
Convenciones de Código Java
2 - Nombres de ficheros
Esta sección lista las extensiones más comunes usadas y los nombres de ficheros.
2.1 Extensiones de los ficheros
El software Java usa las siguientes extensiones para los ficheros:
Tipo de fichero
Extensión
Fuente Java
.java
Bytecode de Java
.class
2.2 Nombres de ficheros comúnes
Los nombres de ficheros más utilizados incluyen:
Nombre de fichero
Uso
GNUmakefile
El nombre preferido para ficheros "make". Usamos gnumake para
construir nuestro software.
README
El nombre preferido para el fichero que resume los contenidos de un
directorio particular.
6
Convenciones de Código Java
3 - Organización de los ficheros
Un fichero consiste de secciones que deben estar separadas por líneas en blanco y
comentarios opcionales que identifican cada sección.
Los ficheros de más de 2000 líneas son incómodos y deben ser evitados.
Para ver un ejemplo de un programa de Java debidamente formateado, ver "Ejemplo de
fichero fuente Java" en la página 26.
3.1 Ficheros fuente Java
Cada fichero fuente Java contiene una única clase o interface pública. Cuando algunas clases
o interfaces privadas estan asociadas a una clase pública, pueden ponerse en el mismo fichero
que la clase pública. La clase o interfaz pública debe ser la primera clase o interface del
fichero.
Los ficheros fuentes Java tienen la siguiente ordenación:
• Comentarios de comienzo (ver "Comentarios de comienzo" en la página 7)
• Sentencias package e import
• Declaraciones de clases e interfaces (ver "Declaraciones de clases e interfaces" en la
página 7)
3.1.1 Comentarios de comienzo
Todos los ficheros fuente deben comenzar con un comentario en el que se lista el nombre de
la clase, información de la versión, fecha, y copyright:
/*
* Nombre de la clase
*
* Informacion de la version
*
* Fecha
*
* Copyright
*/
3.1.2 Sentencias package e import
La primera línea no-comentario de los ficheros fuente Java es la sentencia package. Después
de esta, pueden seguir varias sentencias import. Por ejemplo:
package java.awt;
import java.awt.peer.CanvasPeer;
Nota: El primer componente de el nombre de un paquete único se escribe siempre en
minúsculas con caracteres ASCII y debe ser uno de los nombres de dominio de último nivel,
actualmente com, edu, gov, mil, net, org, o uno de los códigos ingleses de dos letras que
especifican el pais como se define en el ISO Standard 3166, 1981.
3.1.3 Declaraciones de clases e interfaces
7
Convenciones de Código Java
La siguiente tabla describe las partes de la declaración de una clase o interface, en el orden en
que deberian aparecer. Ver "Ejemplo de fichero fuente Java" en la página 26 para un ejemplo
que incluye comentarios.
Partes de la declaración de
una clase o interface
Notas
1
Comentario de documentación
de la clase o interface
(/**...*/)
Ver "Comentarios de documentación" en la página 14 para
más información sobre lo que debe aparecer en este
comentario.
2 Sentencia class o interface
3
Comentario de
implementación de la clase o
interface si fuera necesario
(/*...*/)
Este comentario debe contener cualquier información
aplicable a toda la clase o interface que no era apropiada
para estar en los comentarios de documentación de la clase
o interface.
4 Variables de clase (static)
Primero las variables de clase public, después las
protected, después las de nivel de paquete (sin
modificador de acceso) , y despúes las private.
5 Variables de instancia
Primero las public, después las protected, después las de
nivel de paquete (sin modificador de acceso), y después las
private.
Estos métodos se deben agrupar por funcionalidad más que
por visión o accesibilidad. Por ejemplo, un método de clase
privado puede estar entre dos métodos públicos de instancia.
El objetivo es hacer el código mas legible y comprensible.
6 Constructores
7 Métodos
8
Convenciones de Código Java
4 - Indentación
Se deben emplear cuatro espacios como unidad de indentación. La construcción exacta de la
indentación (espacios en blanco contra tabuladores) no se especifica. Los tabuladores deben
ser exactamente cada 8 espacios (no 4).
4.1 Longitud de la línea
Evitar las líneas de más de 80 caracteres, ya que no son manejadas bien por muchas
terminales y herramientas.
Nota: Ejemplos para uso en la documentación deben tener una longitud inferior,
generalmente no más de 70 caracteres.
4.2 Rompiendo líneas
Cuando una expresión no entre en una línea, romperla de acuerdo con estos principios:
• Romper después de una coma.
• Romper antes de un operador.
• Preferir roturas de alto nivel (más a la derecha que el "padre") que de bajo nivel (más a
la izquierda que el "padre").
• Alinear la nueva linea con el comienzo de la expresion al mismo nivel de la linea
anterior.
• Si las reglas anteriores llevan a código confuso o a código que se aglutina en el
margen derecho, indentar justo 8 espacios en su lugar.
Ejemplos de como romper la llamada a un método:
unMetodo(expresionLarga1, expresionLarga2, expresionLarga3,
expresionLarga4, expresionLarga5);
var = unMetodo1(expresionLarga1,
unMetodo2(expresionLarga2,
expresionLarga3));
Ahora dos ejemplos de roptura de lineas en expresiones aritméticas. Se prefiere el primero, ya
que el salto de linea ocurre fuera de la expresión que encierra los paréntesis.
nombreLargo1 = nombreLargo2 * (nombreLargo3 + nombreLargo4
- nombreLargo5) + 4 * nombreLargo6; // PREFERIDA
nombreLargo1 = nombreLargo2 * (nombreLargo3 + nombreLargo4
- nombreLargo) + 4 * nombreLargo6;
// EVITAR
Ahora dos ejemplos de indentación de declaraciones de métodos. El primero es el caso
convencional. El segundo conduciría la segunda y la tercera linea demasiado hacia la
izquierda con la indentación convencional, asi que en su lugar se usan 8 espacios de
indentación.
9
Convenciones de Código Java
//INDENTACION CONVENCIONAL
unMetodo(int anArg, Object anotherArg, String yetAnotherArg,
Object andStillAnother) {
...
}
//IND
Comentarios de: Convenciones de Código para el lenguaje de programación JAVA (0)
No hay comentarios