Jcc

23
1 Java Convention Code Equipo de Arquitectura Equipo de Arquitectura

description

Charla de Java Convention Code, extraida de sun.com

Transcript of Jcc

Page 1: Jcc

11

Java Convention Code

Equipo de ArquitecturaEquipo de Arquitectura

Page 2: Jcc

22

Por qué?

El 80% del coste del tiempo de vida de una pieza de software se va en mantenimiento.

Casi nunca ningún software es mantenido durante toda su vida por su autor original.

Las convenciones de nombrado mejoran la lectura del software, permitiendo a los ingenieros entender el nuevo código más rápidamente y mejor.

Si lanzamos nuestro código fuente como un producto, necesitamos asegurarnos de que está tan bien empaquetado y limpio como cualquier otro producto que creemos.

Page 3: Jcc

33

Clases/Interfaces

Los nombres de clases deberían ser sustantivos, incluyendo mayúsculas y minúsculas con la primer letra de cada palabra interna en mayúscula. Intente mantener los nombres de clases sencillos y descriptivos. Utilice palabras completas y evite usar acrónimos y abreviaturas (a menos que la abreviatura sea ampliamente usada más que la forma completa, tal como URL o HTML).

<<class>>Persona

atributos

métodos

Page 4: Jcc

44

Métodos

Los nombres de los métodos deberían ser verbos, mezclas de mayúsculas y minúsculas con la primer letra en minúscula y la primer letra de cada palabra interna en mayúscula (CamelCase).

<<class>>Persona

atributos

calcularEdad()obtenerRut()

Page 5: Jcc

55

Variables

Todas las instancias, clases y constantes de clase se escriben usando mayúsculas y minúsculas con la primer letra en minúscula.  Las palabras internas comienzan con letras mayúsculas. Los nombres de variable no deben comenzar con caracteres underscore _ o signo de dólar $, aunque ambos estén permitidos.

Los nombres de variables deberían ser cortos pero con un significado claro. La elección de un nombre de variable debería ser mnemónica, es decir, diseñado para indicar al observador casual su utilización. Deberían evitarse los nombres de variable de un solo caracter excepto para las variables temporales. Algunos nombres de variables temporales son i, j, k, m, y n para enteros; c, d, y e para caracteres.

Page 6: Jcc

66

Constantes

Los nombres de variables declarados como constantes de clase y las constantes ANSI deberían escribirse todas en mayúsculas con palabras separadas por underscores _. (Las constantes ANSI deberían evitarse, para facilitar la depuración.)

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

Page 7: Jcc

77

Constantes

Los nombres de variables declarados como constantes de clase y las constantes ANSI deberían escribirse todas en mayúsculas con palabras separadas por underscores _. (Las constantes ANSI deberían evitarse, para facilitar la depuración.)

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

Page 8: Jcc

88

Package’s and Import’s

Las primeras líneas no comentadas de un archivo Java, correspoden a unaPackage o bien a un Import.

El paquete debe ser descriptivo, inicialmente el pais, la institución, la Aplicación y luego el detalle de los aplicativos.

Los import funcionan para “traer” las clases necesarias en tiempo de ejecución, por ende, SÓLO se debe importar lo que se va a usar. Sentencias como import cl.*; no están permitidas.

package cl.bch.gwt.consultasaldo.client; import java.util.Map; Import java.util.*; //no se acepta!!!

Page 9: Jcc

99

Declaraciones de clase e interfaz

package cl.bch.gwt.consultasaldo.client;Import java.util.Map;/*** Comentarios de Javadoc**/public class/interface Nombre {

Variables de clase(static);Variables de instancia (public, protected, package, private);Constructores (por default primero);Métodos (agrupados por funcionalidad)

}

Page 10: Jcc

1010

Código

TabulaciónLa unidad de tabulación deberían ser cuatro espacios. La forma exacta de la tabulación (espacios ó tabuladores) no se especifica.

Longitud de líneaEvitar las líneas de más de 80 caracteres, ya que algunas herramientas no las manejan bien.

Ruptura de líneas (Wrapping lines)Cuando una expresión no cabe en una única línea, se debe romper de acuerdo a estos principios generales:Romper después de una coma.Romper antes de un operador.Alinear la nueva línea con el principio de la expresión al mismo nivel que la línea anterior.Si las reglas anteriores llevan a un código confuso o demasiado pegado al margen derecho, entonces tabular sólo con 8 espacios.

Page 11: Jcc

1111

Código

someMethod(longExpression1, longExpression2, longExpression3,longExpression4, longExpression5);

var = someMethod1(longExpression1,someMethod2(longExpression2,

longExpression3));

longName1 = longName2 * (longName3 + longName4 - longName5)+ 4 * longname6; // RECOMENDADA

longName1 = longName2 * (longName3 + longName4- longName5) + 4 * longname6; // EVITAR

Page 12: Jcc

1212

Código

// NO UTILIZAR ESTA TABULACIONif ((condition1 && condition2)

|| (condition3 && condition4)||!(condition5 && condition6)) {doSomethingAboutIt();

}// USAR ESTA TABULACION EN SU LUGARif ((condition1 && condition2)

|| (condition3 && condition4)||!(condition5 && condition6)) {

doSomethingAboutIt();}// O USAR ESTA OTRAif ((condition1 && condition2) || (condition3 && condition4)

||!(condition5 && condition6)) {doSomethingAboutIt();

}

Page 13: Jcc

1313

Código

Aquí se muestran tres maneras aceptables de escribir expresiones ternarias:

alpha = (aLongBooleanExpression) ? beta : gamma;

alpha = (aLongBooleanExpression) ? beta: gamma;

alpha = (aLongBooleanExpression)? beta: gamma;

Page 14: Jcc

1414

Comentarios

Los “programas” en Java pueden tener dos tipos de comentarios: comentarios de implementación comentarios de documentación.

Los comentarios de documentación (conocidos como "comentarios Javadoc") son específicos de Java y están delimitados por

/** * Comentario de Javadoc.**/

Los comentarios de documentación se pueden extraer a HTML usando la herramienta javadoc.

Page 15: Jcc

1515

Comentarios

Los “programas” pueden tener cuatro estilos de comentarios de implementación: de bloque (block comments), de una sola línea (single-line comments), por detrás (trailing comments) y de final de línea (end-of-line comments).

/** Este es un comentario de bloque*//* Comentario de una sola línea. */// Comentario de una sola línea.

if (a == 2) {return true; /*

comentario por detrás */} else {

//comentario de fin de línea.return isPrime(a); //

comentario de fin de línea.}

Page 16: Jcc

1616

Declaración de variables y/o atributos

Se recomienda una declaración por línea ya que fomenta los comentarios. En otras palabras,

int level; // nivel de tabulaciónint size; // tamaño de la tabla

Es preferido antes que:int level, size;

No poner tipos diferentes en la misma línea. Por ejemplo:int foo, fooarray[]; // ¡MAL!

InicializaciónHay que intentar inicializar las variables locales donde se declaren. La única razón para no inicializar una variable donde se declara es si el valor inicial depende de algún cálculo que debe ocurrir primero.

ColocaciónPoner las declaraciones sólo al principio de los bloques.

Page 17: Jcc

1717

Declaración de clase e interfaz

Mientras se codifican clases e interfaces Java, se deberían seguir las siguientes reglas de formato:

Ningún espacio entre el nombre del método y el paréntesis "(" que abre su lista de parámetros.

La llave de apertura "{" aparece al final de la misma línea que la sentencia de declaración.

La llave de cierre "}" comienza una línea nueva tabulada para coincidir con su sentencia de apertura correspondiente, excepto cuando es un bloque vacío que la llave de cierre "}" debería aparecer inmediatamente después de la de apertura "{".

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

Page 18: Jcc

1818

Sentencias

Sentencias simplesCada línea debería contener una sentencia como mucho. Por ejemplo:

argv++; // Correctoargc--; // Correctoargv++; argc--; // ¡EVITAR!

Sentencias compuestasLas sentencias compuestas son sentencias que contienen una lista de sentencias encerradas entre llaves "{" y "}".

Las sentencias internas deberían estar tabuladas un nivel más que la sentencia compuesta.

La llave de apertura debería estar al final de la línea que comienza la sentencia compuesta; la llave de cierre debería estar en una nueva línea y estar tabulada al nivel del principio de la sentencia compuesta.

Las llaves se usan en todas las sentencias compuestas, incluídas las sentencias únicas

Page 19: Jcc

1919

Sentencias

Sentencias if, if-else, if-else-if-else:

if (condición) {sentencias;

}if (condición) {

sentencias;} else {

sentencias;}

Nota: Las sentencias if siempre llevan llaves {}. Evitar la siguiente forma, propensa a errores:

if (condición) // ¡EVITAR OMITIR LAS LLAVES! {}sentencia;

if (condición) {sentencias;

} else if (condición) {sentencias;

} else {sentencias;

}

Page 20: Jcc

2020

Sentencias

Sentencias for

Una sentencia for debería tener el siguiente formato:

for (inicialización; condición; actualización) {sentencias;

}

Una sentencia for vacía (aquella en la que todo el trabajo se hace en las cláusulas de inicialización,condición y actualización) debería tener el siguiente formato:

for (inicialización; condición; actualización);

Page 21: Jcc

2121

Sentencias

Sentencias while

Una sentencia while debería tener el siguiente formato:

while (condición) {sentencias;

}

Una sentencia while vacía debería tener el siguiente formato:

while (condición);

Page 22: Jcc

2222

Sentencias

Sentencias switch

Una sentencia switch debería tener el siguiente formato:

switch (condición) {case ABC:

sentencias;/* continua con el siguiente */

case DEF:sentencias;break;

case XYZ:sentencias;break;

default:sentencias;break;

}

Page 23: Jcc

2323

Dudas?Dudas?

Equipo de ArquitecturaEquipo de Arquitectura