Estandares De Programacion

ESTANDARES DE PROGRAMACION

Las convenciones de codificación son importantes para los programadores por varias razones:

• 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 que esté tan bien empaquetado y limpio como cualquier otro producto que desarrollemos.

•

Para que las convenciones funcionen, toda persona que escriba software debe adherirse a ellas.

Reconocimientos

Este documento refleja los estándares de codificación del lenguaje Java presentados en la Especificación del Lenguaje Java, de Sun Microsystems, Inc.

1. Nombres de Ficheros

Se muestra una lista de los sufijos y nombres de ficheros más utilizados:

Extensiones de Ficheros

El lenguaje Java usa los siguientes tipo de sufijos:

Tipo de Fichero

Extensión

Fuente Java .java

Bytecodes Java .class

Nombres de Ficheros sin extensión

Los nombres de ficheros deberán tener siempre el nombre exacto de la clase que representan, para lo cual optara los estándares para el nombre de clases.

2. Organización de Ficheros

Un fichero consta de secciones que deberían estar separadas por líneas en blanco y un comentario opcional identificando cada sección.

Los ficheros de más de 2000 líneas no son entendibles y deberían evitarse.

Ficheros Fuente Java

Todo fichero fuente Java contiene una sola clase pública o un interface. Cuando hay clases privadas e interfaces asociados con una clase pública, se pueden poner dentro del mismo fichero fuente que la clase pública. La clase pública debería ser la primera clase o interface en el fichero. Los ficheros fuente Java tienen el siguiente orden:

• Comentarios de inicio

• Sentencias Package e Import

• Declaraciones de clase o interface.

Comentarios de Inicio

Todos los ficheros fuente deberían empezar con un comentario que liste el nombre de la clase, la información de versión, la fecha y las notas de copyright:

/*

* Classname

*

* @author

* @version

*

* Copyright

*/

Sentencias Package e Import

La primera línea no cometnada de la mayoría de los ficheros fuente Java es una sentencia package. Después de esta pueden seguir sentencias import. Por ejemplo:

package org.sfh.osinerg.maestros;

import org.osinerg.sfh.comun.lists;

Declaraciones de Clase e Interface

La siguiente tabla describe las partes de una declaración de clase o interface, en el orden en que deberían aparecer.

Parte de la clase/Interface Notas

1 Comentario de documentación de Clase/interface (/**...*/) Revisar los estándares de documentación

2 Sentencia class o interface

3 Comentario de implemetnación de Clase/interface (/*...*/), si es necesario Este comentario debería contener cualquier información sobre la clase o el interface que no fuera apropiada para ponerla en el comentario de documentación.

4 Variables de clase (static) Primero las variables de clase pública, luego las protegidas, después las de nivel de paquete (sin modificador de acceso), y por último las privadas.

5 Variables de Ejemplar Primero las variables de clase pública, luego las protegidas, después las de nivel de paquete (sin modificador de acceso), y por último las privadas.

6 Constructores

7 Métodos Estos métodos deberían agruparse por funcionalidad en vez de por ámbito o accesibilidad. Por ejemplo, un método de clase privado puede ir entre dos métodos de ejemplar públicos. El objetivo es hacer la lectura y el entendimiento del código más fácil.

3. Identación

Se deberían usar cuatro espacios como unidad de identación. La construcción exacta de la identación no está especificada (espacios o tabs). Los tabuladores deben ser exactamente cada 8 espacios (no cada 4).

Longitud de Línea

Evitar líneas mayores de 80 caracteres, ya que no son bien manejadas por muchos terminales y herramientas.

Ruptura de Líneas

Cuando una expresión no entre en una sóla línea, se debe romper de acuerdo a estos principio generales:

• Romper después de una coma.

• Romper antes de un operador

• Preferir las rupturas de alto nivel a las de bajo nivel.

• Alinear la nueva línea con el principio de la expresión al mismo nivel de la línea anterior.

• Si las reglas anteriores conducen a la confusión del código o código que llega al margen derecho, sólo identamos 8 espacios.

Aquí tenemos algunos ejemplos de rupturas de llamadas a métodos:

...