INGENIERIA EN SISTEMAS COMPUTACIONALES
Sistemas integrales
ESTÁNDAR DE CODIFICACIÓN
JAVA
1
INGENIERIA EN SISTEMAS COMPUTACIONALES
Sistemas integrales
Introducción
Se definen un estándar de codificación porque es un estilo de programación
homogéneo en un proyecto permite que todos los participantes lo puedan
entender en menos tiempo y que el código en consecuencia sea mantenible.
Nombres de ficheros
Sufijos de ficheros en Java1:
Código fuente: .java
Código compilado: .class
Nombres de ficheros comunes:
README: Resumen de información importante relativa al directorio en el que
está ubicado
Organización de ficheros
Un fichero consta de secciones separadas por líneas en blanco y líneas de
comentario, ningún fichero debe tener más de 2000 líneas de código.
Ficheros de código fuente
Cada fichero contiene una única clase o interface. Si hay una clase privada o
una interfaz asociada a una clase pública se puede poner en el mismo
fichero. La clase pública debe ser la primera.
Ordenación de las secciones en un fichero de código fuente
Estas secciones deben ir separadas por una línea en blanco
Sentencia: package xxx.yyy;
Sentencias de importación. Ej: import java.util.ArrayList;.
No hay líneas en blanco entre ellas.
Código de la clase. Va precedido por comentarios tipo javadoc con la
siguiente información:
Prólogo explicativo de la clase (opcional), autor, versión, referencias a otros
elementos de código si se considera que debe haberlas.
Indentación
2
INGENIERIA EN SISTEMAS COMPUTACIONALES
Sistemas integrales
La unidad de indentación de bloques de sentencias son 4 espacios
Líneas largas
Cuando una línea no quepa en una única línea se debe fraccionar
atendiendo a estos principios generales.
Fraccionar después de una coma
Fraccionar después de un operador
Es mejor romper unidades de alto nivel que de bajo nivel.
Ejemplo:
longName1 = longName2 * (longName3 + longName4 - longName5)
+ 4 * longname6; // Mejor
longName1 = longName2 * (longName3 + longName4
- longName5) + 4 * longname6; // Peor
Si las reglas anteriores producen código confuso utilizar indentación de 8
caracteres. Ejemplo:
// NO USAR ESTA INDENTACION
if ((condition1 && condition2)
|| (condition3 && condition4)
||!(condition5 && condition6)) {
doSomethingAboutIt(); // SE CONFUNDE CON LAS ANTERIORES
}
// USAR ESTA INDENTACION
if ((condition1 && condition2)
|| (condition3 && condition4)
||!(condition5 && condition6)) {
doSomethingAboutIt();
}
// O ESTA
if ((condition1 && condition2) || (condition3 && condition4)
||!(condition5 && condition6)) {
doSomethingAboutIt();
}
Comentarios
Normas general a seguir en toda documentación:
1. Los comentarios deben añadir claridad al código.
2. Deben contar el por qué y no el cómo.
3. Deben ser concisos.
4. Idealmente hay que escribir la documentación antes que el código.
3
INGENIERIA EN SISTEMAS COMPUTACIONALES
Sistemas integrales
Hay dos tipos de comentarios: Comentarios de implementación y
comentarios de documentación. Los comentarios de implementación son del
tipo: // ... o /*
... */. Los comentarios de documentación son del tipo: /** ... */. Los
comentarios de implementación describen el código, los de documentación
una visión de más alto nivel para gente que no tiene el código a mano y que
sólo quiere usarlo. La información de los comentarios no debe ser evidente,
deben ser cosas que no están contenidas en el código Los comentarios no
deben estar en cajas dibujadas con asteriscos o similar ni deben incluir
caracteres extraños.
Comentarios de implementación
Comentarios de bloque: Al comienzo de cada fichero o bloque. No se usan
en este proyecto Comentarios de linea: Son comentarios explicativos de una
parte pequeña del código. Sintaxis: // ... o /* ... */
Comentarios de documentación
Son los comentarios destinados a ser procesados por javadoc.
Importante: No se pueden usar comentarios de documentación para bloques
de código dentro de métodos porque javadoc los asigna a la primera
declaración que encuentre detrás de ellos
La indentación correcta es:
/**
* Comentario sobre la clase A
*/
public class A { ... }
Declaraciones
Número de declaraciones por línea
Se debe declarar cada variable en una línea distinta, de esta forma cada
variable se puede comentar por separado.
Ejemplo:
int level, size; // Mal
int level; // Indentation level
int size; // Size of table
Los arrays se deben declarar de este modo:
double[] table; // Bien
double []table; // Mal
4
INGENIERIA EN SISTEMAS COMPUTACIONALES
Sistemas integrales
Inicialización
Inicializar cada variable en su declaración a menos que su valor inicial
dependa de algún cálculo
Localización
En el comienzo de los bloques. La única excepción es el bucle for. No se
deben declarar variables con el mismo nombre que otras en un método
Declaraciones de clases e interfaces
Se siguen estas reglas:
No hay espacio entre el nombre del método, el paréntesis y la lista de
parámetros
Se abre la llave { al final de la misma línea que la declaración
La llave de } debe aparecer en línea aparte con la misma indentación que el
método o clase que cierra.
Sentencias
Sentencias simples
Cada línea debe contener una sola sentencia. Ejemplos
argv++; // Bien
argc++; // Bien
argv++; argc++; // Mal
Sentencias compuestas
Son las que están entre llaves { y }
Deben estar indentadas a un nivel superior que el precedente
Todas las sentencias del tipo if o for, while, do ... while deberán tener llaves
aunque sólo contengan una sentencia, de esta forma se evita la
introducción accidental de errores si se añaden posteriormente sentencias
Ejemplos:
Sentencia if
if (condition) {
statements;
}
if (condition) {
statements;
} else {
statements;
}
5
INGENIERIA EN SISTEMAS COMPUTACIONALES
Sistemas integrales
if ( condition) {
statements;
} else if (condition) {
statements;
} else {
statements;
}
Sentencia for
for ( initialization; condition; update) {
statements;
}
for ( initialization; condition; update);
La nueva versión del for tiene el siguiente formato
for (Declaration : List) {
statements;
}
Ejemplo. Antes:
void cancelAll(Collection c) {
for (Iterator i = c.iterator(); i.hasNext(); ) {
TimerTask tt = (TimerTask) i.next();
tt.cancel();
}
}
Después:
void cancelAll(Collection c) {
for (Object o : c) {
((TimerTask)o).cancel();
}
}
Sentencia while:
while (condition) {
statements;
}
while (condition);
Sentencia do-while:
do {
statements;
} while ( condition);
La sentencia switch tiene este formato e indentación
switch ( condition) {
case ABC:
statements;
/* El comentario tambien indentado */
case DEF:
statements;
break;
case XYZ:
statements;
break;
6
INGENIERIA EN SISTEMAS COMPUTACIONALES
Sistemas integrales
default:
statements;
break;
}
La sentencia try ... catch
try {
statements;
} catch (ExceptionClass e) {
statements;
}
Si está seguida por finally:
try {
statements;
} catch (ExceptionClass e) {
statements;
} finally {
statements;
}
Sentencias de retorno
No se pondrá la expresión de retorno entre paréntesis a menos que con ello
se gane en claridad
Espacio en blanco
Líneas en blanco
Se deben usar dos líneas en blanco entre:
Diferentes secciones de un fichero de código fuente
Entre clases y definiciones de interfaz
Se debe usar una línea en blanco:
Métodos
Variables locales de un método y la primera sentencia
Antes de un bloque o un comentario de línea (para que se sepa de un
vistazo que es lo que comenta)
Entre diferentes secciones lógicas dentro de un fichero (más
legibilidad)
Caracteres de espacio
Se deben usar en las siguientes circunstancias:
Entre un paréntesis cerrado y una llave
Después de una coma en la lista de parámetros de un método
Entre operadores binarios: +, -, =, etc. Nunca entre un operador uno-
ario y su operando
La sentencia for y su paréntesis. Ejemplo: for (expr1, expr2, expr3);
7
INGENIERIA EN SISTEMAS COMPUTACIONALES
Sistemas integrales
Casts. Ejemplo: myMethod((int) (cp 5), ((int) (i + 3)) + 1);+
Asignación de nombres
Esta es la sección más importante. Las normas genéricas son:
Se usan descriptores en inglés que dejan claro el cometido de la
variable, método o clase.
Se usa terminología aplicable al dominio.
Si se usan abreviaturas hay que mantener en algún sitio una lista de
lo que significan.
Evitar en lo posible los nombres largos (menos de 15 letras sería lo
ideal)
Evitar nombres que difieran en una letra o en el uso de mayúsculas.
Un nombre no debería constar de más de dos palabras.
No usar siglas en los nombres a menos que queden muy largos o
sean siglas conocidas por todos.
Cada tipo de elemento debe nombrarse con una serie de reglas
determinadas.
Paquetes: Todo en minúsculas. Cada palabra es más específica que la
anterior
Clases e interfaces: Nombres. La inicial en mayúscula
Métodos: Deben ser verbos. La primera letra de la primera palabra en
minúsculas, el resto de las palabras empiezan por mayúsculas
Variables: Deben comenzar por minúscula. No se utilizará en ningún caso
el carácter "_"
Constantes: Todo en mayúscula. Si son varias palabras, unidas por el
carácter "_"
