Estandares de Desarrollo de Programacion en Java

CODIGO: CIGI005GI
NOMBRE DEL DOCUMENTO:
INSTRUCCIÓN DE ESTÁNDARES DE CODIFICACIÓN

PARA PROGRAMACIÓN EN JAVA
DISTRIBUCIÓN :
COPIA N° :
ENTREGADO A:
APROBADO
REV ELABORADO POR: FIRMA REVISADO POR : FIRMA FIRMA FECHA
POR:
1 TATIANA FLORES ALECXY DIAZ RAFAEL CACERES 2011/08

2 RAFAEL
TATIANA FLORES ALECXY DIAZ RAFAEL CACERES
CACERES 2012/01
3 TATIANA FLORES ALECXY DIAZ RAFAEL CACERES
RAFAEL CACERES 2012/06
RAFAEL CACERES
Este Documento es vigente solo en medios Electrónicos / Propiedad de Corporación Aceros Arequipa S.A: Prohibida su
reproducción total o parcial sin autorización del Representante de la Dirección
CODIGO: CIGI005GI
Instrucción de Estándares REVISIÓN: 3
PAGINA:2 de 18
de Codificación para Programación en Java
APROBADO: R.C.G.
FECHA: 2012/06
1. OBJETIVO
Definir estándares de codificación para programación en Java de modo que permitan contar con
código de programación legible y entendible por cualquier programador que desarrolle con
tecnología Java, de tal forma que si el creador de un bloque de código no está presente se puedan
hacer mantenimientos a sus desarrollos iniciales, además de permitir hacer análisis sobre los
mismos para evaluar la posibilidad de posibles adecuaciones.
2. ALCANCE
La presente Instrucción se aplica a todos los desarrollos en Java que se lleven a cabo para la
Corporación Aceros Arequipa sean estos realizados por el personal del Area de Informática o por
los Proveedores Outsoursing.
3. RESPONSABILIDADES
3.1 Gerente de Informática (GI).- Es el responsable de aprobar la presente instrucción.

3.2 Subgerente de Desarrollo Informático (JDI).- Es el responsable de establecer, difundir y
asegurar que los desarrollos efectuados en JAVA a nivel corporativo cumplan con los
estándares definidos en la presente instrucción.
3.3 Analista de Sistemas (AS).- Comprendido por los analistas de sistemas, analista funcional, son
los responsables de ejecutar y registrar lo descrito en la presente instrucción, de coordinar la
capacitación sobre ella y velar por el cumplimiento y aplicación de esta instrucción. Así como
del registro y notificaciones del incumplimiento del personal de informática de esta instrucción.
3.4 Personal de Informática.- Comprendido por los analistas programadores, programador,
programador junior; son los responsables de ejecutar y registrar lo descrito en la presente
instrucción.
4. DOCUMENTOS
4.1 Documentos de Referencia: ISO 9001:2000 Requisito 4.2.3
4.2 Documentos de Consulta: Manual de Gestión de Calidad

“Procedimiento para el Control de los Documentos”
5. DEFINICIONES
5.1 Outsourcing.- Contrato por el cual un tercero (puede ser una empresa o un profesional),
desarrolla o mantiene una aplicación Informática, para proveernos un software de acuerdo a
las especificaciones particulares que le hemos detallado.
5.2 Componentes de software.- Se refiere a los programas, pantallas, reportes, triggers, funciones,
bibliotecas, etc. que forman parte de un software.
5.3 Poner en producción: Se refiere a la instalación de los componentes de software en la
infraestructura informática de la empresa para disponibilidad de los usuarios finales y con data
oficial. Por ejemplo: El sistema de facturación tiene etapas de diseño, análisis, pruebas, etc., pero
cuando se instala y los usuarios de ventas comienzan a usarlo se dice que la aplicación fue
“puesta en producción”.
CODIGO: CIGI005GI
PAGINA:3 de 18
APROBADO: R.C.G.
FECHA: 2012/06
5.4 El compilador del lenguaje java de igual manera que lo hace cualquier otro compilador de otro
lenguaje tiene como entrada archivos fuente y obtiene como salida archivos objeto. En el caso
particular del lenguaje java se tiene lo siguiente:
Archivos Descripción
Fuente Los archivos fuente en el lenguaje de programación java tienen la extensión .java.
Objeto Los archivos objeto que genera el compilador java contienen bytes codes en la
terminología de java y tienen la extensión .class
Jar Los archivos jar son un formato que permite el transporte de varias clases que
conformen una biblioteca, aplicación, componente web, u cualquier otro
componente dentro del lenguaje java que abarque tanto archivos .class o
recursos que utilice, tales como archivos de texto, archivos .xml etc. Este formato
es una manera compacta y estandar de portabilidad en cualquier plataforma java.
War Aplicación web java empaquetada o comprimida lista para ser desplegada en
cualquiera de los servidores que brindan servicios para este tipo de aplicaciones
web.
6. INSTRUCCIÓN
Cuando se utilice un nombre para identificar cualquier construcción se debe de definir un nombre
simple o un nombre compuesto con la primera letra en mayúscula de cada parte que conforme el
nombre, y se debe de evitar el uso de abreviaciones a menos de que la misma sea la mayormente
conocida en la jerga de TI. Por ejemplo, un archivo fuente java lo podremos nombrar como:
CuentaAhorro.java
Una excepción a esta regla será cuando se asigne nombres a métodos en los cuales se utilizan
verbos y cuyas primeras letras aparecen en minúsculas y los siguientes elementos del nombre
aparecen según la convención descrita aquí.
Evite nombres largos, de preferencia menor a 15 caracteres y evite usar el guión bajo, ya que éste
esta designado para propósitos del sistema.
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 deberían evitarse.
6.1Convenciones de Nombrado
Las convenciones de nombrado hacen los programas más entendibles haciéndolos más fáciles
de leer. También pueden proporcionar información sobre la función del identificador, por
ejemplo, si es una constante, un paquete o una clase, lo que puede ayudarnos a entender el
código.
CODIGO: CIGI005GI
PAGINA:4 de 18
APROBADO: R.C.G.
FECHA: 2012/06
6.1.1 Nombrado de Aplicaciones (Proyecto)
Tipo de Reglas de Nombrado Ejemplos

Identificador
Aplicación Las aplicaciones se deben nombrar con un prefijo de máximo 8 SIPILSAP: Sistema
caracteres. (NNNNNZZZ). de Pintado de
Donde: NNNNN es la identificación de la aplicación , Locales
ZZZ es la denominación SAP
Procedimien Los procedimientos batch se deben nombrar con un prefijo ProcAcdimAgentesS
tos Batch “proc” y un nombre identificador de máximo 16 caracteres. AP : Generación de
(procNNNNNNNNNNNNNZZZ) documentos para
Donde NNNNNNNNNNNNN es la identificación de la agentes ACEDIM.
aplicación,
WebServices Los web services se deben nombrar con un un nombre JavaSsoSAPWs :
identificador de máximo 16 caracteres y un sufijo “Ws”. Consulta datos
Donde: NNNNNNNNNNNNN es la identificación de la adicionales de
aplicación, usuario en SSO
6.1.2 Nombrado de paquetes

Identificador
Paquetes Los prefijos de un nombre de paquete único siempre se escriben com.aasa.sarchsap.b
en letras ASCII minúsculas y deberían ser uno de los nombres de ean
dominios de alto nivel, actualmente com. El segundo componente com.aasa.sarchsap.d
del nombre de un paquete tiene que ser el nombre de la empresa ao
(aasa, commit). com.aasa.sarchsap.a
Los componentes subsecuentes deben seguir la convención de ction
nombramiento la cual indica que deben ser nombres descriptivos com.aasa.sarchsap.f
que engloban el dominio del problema que las clases presentes en orm
el paquete resuelven. com.aasa.sarchsap.l
ogic
6.1.3 Nombrado de clases

Identificador
Clases Los nombres otorgados a las clases deben ser nombres propios, class Cliente
mezclando mayúsculas y minúsculas con la primera letra de cada class ClienteAction
palabra interna en mayúscula. Los nombres de las clases deben class
ser simples y descriptivos. Utilizar solo palabras y evitar el uso de ClienteListaAction
acrónimos y abreviaciones (a menos que esta sea la mas
conmunmente utilizada que la forma larga, tales como URL o
HTML).
CODIGO: CIGI005GI
PAGINA:5 de 18
APROBADO: R.C.G.
FECHA: 2012/06
6.1.4 Nombrado de interfaces

Identificador
Interfaces Los nombres de interfaces se tratan igual que los nombres de Interface
clases IcustomerDao
6.1.5 Nombrado de metodos

Identificador
Métodos Los métodos deberían ser verbos, en mayúsculas y minúsculas borrarOrden()
con la primera letra del nombre en minúsculas, y con la primera modificarOrden()
letra de cada palabra interna en mayúsculas. grabarOrden()
6.1.6 Nombrado de variables

Los nombres de variables siguen una convención del tipo de notación Húngara en la cual en el nombre
de la misma se describe el ámbito y tipo de la variable.

Identificador
Variables Las variables, tanto de ejemplar, de clase, como las constantes de String strPv_ruc
clase se escriben en mayúsculas y minusculas y con la primera Double dblPv_peso
letra del nombre en minúsculas, y con la primera letra de cada Int intPv_piezas
palabra interna en mayúsculas.
Los nombres de variables no deben empezar con los caracteres
subrayado "_" o dollar "$", incluso aunque estén permtidos. Los
nombres de variables deberían ser cortos y llenos de significado.
La elección de una variable debería ser mnemónica-es decir,
diseñada para indicar al observador casual su utilización. Se
deben evitar los nombres de variable de un sólo caracter, excepto
para variables temporales. Algunos nombres comunes de este tipo
de variables son: i, j, k, m, y n para enteros.
A continuación se describen los tipos de datos que maneja el lenguaje Java:

boolean
Primitivos Integrales: byte, short, int, long, char.
Punto flotante: float, double.
Numéricos
Tipos
Class
Referencia
Interface
Arrays
CODIGO: CIGI005GI
PAGINA:6 de 18
APROBADO: R.C.G.
FECHA: 2012/06
La sintaxis para el nombramiento de variables debe seguir el siguiente patrón:
prefijo-tipo-varible + prefijo-ambito + ‘_’ + NombreDescriptivo
6.1.6.1 Prefijos para tipo de variable:
Prefijo Tipo de Variable
. bte Byte
. sht Short
. int Int
. lng Long
. chr Char
. flt Float
. dbl Double
. bln Boolean
Referencia
. obj Instancias de clase(Objetos) o interfaces
. str String
. a+{prefijo-tipo-elementos} Arreglos
6.1.6.2 Prefijos de ámbito:
El ámbito de una variable será de acuerdo a los modificadores de ámbito: public, protected, private, pero
también podemos encontrar variables locales a métodos. Los prefijos a utilizar en estos casos se
describen en la siguiente tabla:
Prefijo Ámbito
Pb Variables de clase o de instancia que sean public
Pt Variables de instancia que sean protected
Pv Variables de instancia que sea private
L Variables locales a métodos
A Argumentos en métodos
Af Argumentos en métodos que sean final
6.1.6.3 Nombre Descriptivo:
En el caso que el nombre descriptivo sea compuesto , escribir la primera letra de cada palabra interna en
mayúsculas.
Ejemplo: strL_fechaCumpleanios
CODIGO: CIGI005GI
PAGINA:7 de 18
APROBADO: R.C.G.
FECHA: 2012/06
6.1.7 Nombrado de constantes

Identificador
Constantes Los nombres de variables constantes de clases y static final int MIN_WIDTH = 4
las constantes ANSI deberían escribirse todo en static final int MAX_WIDTH = 99
mayúsculas con las palabras separadas por
subrayados (“_”). (Se deberían evitar las
constantes ANSI para facilitar la depuración.)
6.1.8 Nombrado de Archivos JSP

Identificador
JSP El nombrado para este tipo de archivos consta de acdim_agrProducto.jsp
dos partes, las cuales se definen como nombre del balscsap_agrObjetivo.jsp
aplicativo(JPLASAP, ACDIMSAP, etc) y el nombre
del archivo mismo separados por un “_”
(subrayados), como resultado el nombrado seria el
siguiente “nombreaplicativo_nombrearchivo.jsp”.
6.2Ficheros Fuente Java
Todo fichero fuente Java contiene una sóla clase pública o una 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 e interface.
6.3Comentarios de Inicio
Todos los ficheros fuente deberían empezar con un comentario. Este comentario inicial tendrá la
siguiente información:
Elemento Descripción
Nombre de clase Proporciona el nombre otorgado a la clase public top-level
Nombre clases asociadas Proporciona el nombre de las clases private o de paquete declaradas en
este mismo archivo fuente. Este campo debe de estar presente en caso de
que el archivo .java contenga mas de una declaración de clase y/o interface
Información de versión Contiene información de versión
Fecha creación Contiene la fecha de creación del archivo java
Autor original Nombre de la persona encargada de la creación inicial del archivo fuente
CODIGO: CIGI005GI
PAGINA:8 de 18
APROBADO: R.C.G.
FECHA: 2012/06
Descripción Contiene breve descripción del propósito de la clase

Fecha última modificación Contiene la fecha de la última modificación del archivo java
Responsable última Contiene el nombre de la persona responsable de la última modificación al
modificación archivo fuente
Descripción última modificación Una breve explicación de no mas de 50 caracteres con la descripción de la
última modificación realizada
Copyright Nota legal de derechos reservados del código implementado en el archivo
fuente
Por cada método colocar el siguiente bloque de comentarios
Método Nombre de método

Descripción Contiene la descripción del método
Fecha Fecha del cambio
Responsable
Nombre responsable
Descripción
Descripción del cambio
6.4Sentencias Package e Import
La primera línea no comentada de la mayoría de los ficheros fuente Java es una sentencia
package. Después de esta pueden seguir sentencias import. Por ejemplo:
package com.aasa.sarch.dao;
import java.util.ArrayList;
import java.util.Collection;
import javax.sql.DataSource;
import java.sql.SQLException;
import com.aasa.sipilsap.dao.accesoDaoException;
import com.aasa.sipilsap.bean.Cliente;
El nombramiento de paquetes debe seguir los siguientes lineamientos:

 Siempre escribir en letras minúsculas ASCII el nombre del paquete.
 Como primer elemento componente del nombre del paquete utilizar com
 Como segundo elemento componente del nombre del paquete utilizar las siglas del nombre
de la empresa que desarrolla.
 Del tercer elemento en adelante utilizar un nombre descriptivo del objetivo que satisface el
paquete dentro del dominio del problema que resuelve (Todo en minúsculas).
6.5Declaraciones 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.
CODIGO: CIGI005GI
PAGINA:9 de 18
APROBADO: R.C.G.
FECHA: 2012/06
Parte de la Clase/Interface Notas

Comentario de documentación de
Clase/Interface (/**comentario*/)
Sentencia class o interface
Comentario de implementación de Este comentario debería contener cualquier información sobre la
Clase/Interface (/*comentario de clase o el interface que no fuera apropiada para ponerla en el
implementación*/), si es necesario comentario de documentación
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.
Variables de Instancia 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.
Constructores
Métodos de implementación Los métodos que implementan el comportamiento expuesto en la
interface por medio de los métodos public al cliente
Métodos de modificación Los métodos que modifican el estado de la clase
Métodos selectores Los métodos get y set
6.6Identación
Para lograr la claridad en el código fuente hay que estructurar los archivos fuente con cierta
identación para distinguir las instrucciones así como cualquier otra construcción del lenguaje.
Para esto se establecen las siguientes convenciones:
6.6.1 Longitud de Línea
Evitar líneas mayores de 80 caracteres, ya que no son bien manejadas por muchos terminales y
herramientas.
6.6.2 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.
someMethod(longExpression1, longExpression2, longExpression3,
longExpression4, longExpression5);
var = someMethod1(longExpression1,
someMethod2(longExpression2,
longExpression3));
 Romper antes de un operador

// RECOMENDADO
longName1 = longName2 * (longName3 + longName4 – longName5)
+ 4 * longname6;
// EVITAR
longName1 = longName2 * (longName3 + longName4
- longName5) + 4 * longname6;
 Preferir las rupturas de alto nivel a las de bajo nivel.

CODIGO: CIGI005GI
PAGINA:10 de 18
APROBADO: R.C.G.
FECHA: 2012/06
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 se estrella contra el
margen derecho, sólo identamos 8 espacios.
// IDENTACION RECOMENDADA a 8 espacios, para evitar muy poca profundidad

private static synchronized horkingLongMethodName(int anArg,
Object anotherArg, String yetAnotherArg,
Object andStillAnother) {
...
}
La ruptura de líneas de sentencias if generalmente usará la regla de 8-espacios. Por ejemplo:
//NO USAR ESTA IDENTACION

if ((condition1 && condition2)
|| (condition3 && condition4)
||!(condition5 && condition6)) { //BAD WRAPS
doSomethingAboutIt(); //MAKE THIS LINE EASY TO MISS
}
// USAR ESTA IDENTACION

if ((condition1 && condition2)
|| (condition3 && condition4)
||!(condition5 && condition6)) {
doSomethingAboutIt();
}
//O USAR ESTA IDENTACION

if ((condition1 && condition2) || (condition3 && condition4)
||!(condition5 && condition6)) {
doSomethingAboutIt();
}
6.7Comentarios
Los programas Java pueden tener dos tipos de comentarios: los comentarios de implementación
y los comentarios de documentación.
Los comentarios de implementación son un medio para la documentación acerca del código o
para documentar acerca de una particular implementación. Están delimitados por /*...*/, y //
Los comentarios de documentación son únicos de Java y están delimitados por /**...*/. Los
comentarios de documentación se pueden extraer a ficheros HTML usando la herramienta
javadoc.
Los comentarios de implementación son un medio para la documentación acerca del código o
para documentar acerca de una particular implementación.
Los comentarios de documentación pueden ser extraídos a archivos HTML utilizando la

herramienta javadoc y son un medio para describir la especificación del código, desde la
perspectiva independiente de la implementación; para ser leído por desarrolladores que podría
CODIGO: CIGI005GI
PAGINA:11 de 18
APROBADO: R.C.G.
FECHA: 2012/06
no necesariamente tener el código fuente a la mano. Este tipo de comentarios describe que hace
la clase y/o método mas no como lo hace.
Para los comentarios se recomienda tener en cuenta lo siguiente:
Evitar encerrar los comentarios en grandes cajas asteriscos y otros caracteres.
Evitar el uso de caracteres especiales dentro de comentarios tales como form-feed y backspace.
6.7.1 Comentarios de Implementación
 Comentarios de Bloque (/*…*/): Se usaran para proporcionar descripciones de archivos,
métodos, estructuras de datos y algoritmos.
Estos se pueden usar en el inicio de un archivo, antes de cada método o dentro de métodos.
Los comentarios de bloque dentro de una función o método tienen que identarse al mismo
nivel que el código que ellos describen.
Un comentario de bloque tiene que ser precedido por una línea en blanco.
 Comentarios de línea simple(/*…*/): Se usarán para comentarios cortos (de menos de 30

caracteres) que aparecerán sobre una sola línea identada al nivel del código que sigue.
Un comentario de línea simple tiene que ser precedido por una línea en blanco.
Se usarán para identificar la intención de una comprobación de una condición en una
instrucción if, while, for, etc.
 Comentarios trainling(/*…*/): Comentarios muy breves (de no mas de 15 caracteres) sobre

la misma línea que el código que ellos describen, pero tienen que ser desplazados lo
suficiente de las instrucciones que describe.
Si más de un comentario aparece en un bloque de código, se tiene que identar éstos al

mismo establecimiento de identación(4 u 8 caracteres).
Comentarios de fin de linea(//): Se pueden utilizar de la misma manera que los comentarios
trainling.
6.7.2 Comentarios de Documentación
Los comentarios Doc describen clases, interfaces, constructores, métodos, y campos Java. Cada
comentario doc se establece dentro de los delimitadores /**…*/, con un comentario por clase,
interface, o miembro.
 Este tipo de comentarios tienen que aparecer justo antes de la declaración.

 De ser necesario proporcionar información acerca de una clase, interface, variable o método
que no es apropiado para documentación, utilizar un comentario de bloque de
implementación o comentario de línea simple inmediatamente después de la declaración.
 Los comentarios Doc no pueden posicionarse dentro de un método o constructor, debido a
que Java asocia comentarios de documentación con la primera declaración después del
comentario.
6.8Declaraciones
Las convenciones para las declaraciones Java son las siguientes:
CODIGO: CIGI005GI
PAGINA:12 de 18
APROBADO: R.C.G.
FECHA: 2012/06
 Se debe de tener una declaración por línea y se debe de comentar la utilización que se da a
la declaración dentro del código.
Alinear todos los identificadores de diferentes líneas, utilizando los espacios o tabs
adecuados para ello. Por ejemplo:
int level; //nivel de indentación.
Object currentEntry; //entrada de tabla seleccionada actualmente.
 Inicializar las variables locales donde estas son declaradas.
 Poner las declaraciones únicamente al inicio de los bloques (un bloque es cualquier código
encerrado por los caracteres de llaves “{” y “}”).
 No utilizar declaraciones locales que oculten declaraciones de niveles más alto.
6.8.1 Declaración de clases e interfaces
 No utilizar espacios entre el nombre de un método y el paréntesis que inicia la lista de

parámetros.
 La llave de apertura del bloque “{” debe de aparecer en la misma línea que la instrucción de
declaración.
 La llave de cerradura “}” del bloque debe alinearse al inicio de la instrucción, excepto cuando
esta es una instrucción null en cuyo caso tiene que aparecer inmediatamente después de la
llave de apertura “{”.
 Los métodos deben de estar separados por una línea en blanco uno de otro.
6.8.2 Declaración de instrucciones

Seguir las siguientes convenciones estándar para la codificación de statements(intrucciones)
java, en programas escritos con el lenguaje Java:
 Cada linea tiene que contener solo una instrucción. Ejemplo:

Argv++; //correcto
Argc--; //correcto
Argv++; Argc--; //evitar
 Las instrucciones compuestas(instrucciones encerradas por llaves “{” “}”) tienen que:
 Estar indentadas un nivel mas que la instrucción compuesta.
 La llave de apertura tiene que aparecer al final de la linea que inicia la instrucción
compuesta; la llave de cerradura tiene que iniciar una nueva línea y tiene que alinearse a
la instrucción compuesta.
 Las llaves deben de ser utilizadas en todos los casos incluyendo los casos de
instrucciones compuestas simples, como en los casos de instrucciones if, for, while que
pueden incluir solo una instrucción como instrucción compuesta.
 Siempre utilizar llaves en instrucciones if.
 Incluir un comentario trailing o de fin de línea indicando la intención de la condición, en
función del significado de la expresión que se utiliza.
 Una instrucción return con valor no debe de utilizar paréntesis a menos de que haga más
claro el valor de retorno. Ejemplo:
o return;
CODIGO: CIGI005GI
PAGINA:13 de 18
APROBADO: R.C.G.
FECHA: 2012/06
o return myDisk.size();
o return (size ? size : defaultSize);
6.8.3 Declaraciones de Clases e Interfaces

Cuando codificamos clases e interfaces Java, se deben seguir las siguientes reglas de formateo:
 No debe haber ningún espacio entre el nombre y el paréntesis “(“ que inicia la lista de
parámetros.
 El corchete abierto “{” aparece en la misma línea que la declaración.
 El corchete cerrado “}” empieza una línea por sí mismo, identado a su correspondiente
sentencia de apertura, excepto cuando es una sentencia null en la que el “}” debería
aparecer inmediatamente después del “{“:
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.
6.9Sentencias
6.9.1 Sentencias Simples
Cada línea debe contener como máximo una sentencia. Por ejemplo:
argv++; // Correct
argc++; // Correct
argv++; argc--; // EVITAR!
6.9.2 Sentencias Compuestas

Las sentencias compuestas son sentencias que contienen listas de sentencias encerradas entre
corchetes “{ sentencias }”.
Las sentencias encerradas deben identarse uno o más niveles que la sentencia compuesta.
El corchete de apertura debe estar al final de la línea que empieza la sentencia compuesta; el
corchete de cierre debería empezar una nueva línea y estar identado con el principio de la
sentencia compuesta.
Los corchetes se usan alrededor de todas las sentencias, incluso para sentencias simples,
cuando éstas forman parte de una estructura de control como una sentencia if-else o for. Esto
hace más fácil la adición de sentencias sin introducir errores debido al olvido de los corchetes.
CODIGO: CIGI005GI
PAGINA:14 de 18
APROBADO: R.C.G.
FECHA: 2012/06
6.9.3 Sentencias de Retorno

Una sentencia de retorno no debería usar paréntesis a menos que el valor de retorno sea más
óbvio de esa forma. Por ejemplo:
return;
return myDisk.size();
return (size ? size : defaultSize);
6.9.4 Sentencias if, if-else, if else-if else

Las sentencias del tipo if-else deberían tener la siguiente forma:
if ( condition) {
statements;
}
if ( condition) {
statements;
} else {
statements;
}
if ( condition) {
statements;
} else if ( condition) {
statements;
} else {
statements;
}
Nota:
Las sentencias if siempre usan corchetes. Debemos evitar el siguiente error:
if ( condition) //EVITAR OMITIR LLAVES {}!
statement;
6.9.5 Sentencias for

Una sentencia for debería tener la siguiente forma:
for ( initialization; condition; update) {
statements;
}
Una sentencia for vacía (una en la que todo el trabajo se hace en las claúsulas de inicialización,
condición y actualización) debería tener la siguiente forma:
for ( initialization; condition; update);
Cuando usamos el operador coma en las claúsulas de inicialización o actualización de una
sentencia for, debemos evitar la complejidad de usar más de tres variables. Si es necesario,
debemos usar sentencias separadas antes del bucle for (para la claúsula de inicialización) o al
final del bucle (para la claúsula de actualización).
6.9.6 Sentencias while
Una sentencia while debería tener la siguiente forma:

while ( condition) {
statements;
}
CODIGO: CIGI005GI
PAGINA:15 de 18
APROBADO: R.C.G.
FECHA: 2012/06
Una sentencia while vacía debería tener la siguiente forma:

while ( condition );
6.9.7 Sentencias do-while

Una sentencia do-while debería tener la siguiente forma:
do {
statements;
} while ( condition);
6.9.8 Sentencias switch

Una sentencia switch debería tener la siguiente forma:
switch ( condition) {
case ABC:
statements;
/* falls through */
case DEF:
statements;
break;
case XYZ:
statements;
break;
default:
statements;
break;
}
Cada vez que un case cae (no incluye una sentencia break), debemos añadir un comentario
donde normalmente iría la sentencia break. Esto se ve en el ejemplo de código anterior con el
comentario /* falls through */.
Toda sentencia switch debería incluir un valor default. El break en el case por defecto es
redundante, pero evita un error de caída si añadimos después otro case.
6.9.9 Sentencias try-catch

Una sentencia try-catch debería tener la siguiente forma:
try {
statements;
} catch (ExceptionClass e) {
statements;
}
Una sentencia try-catch también podría ir seguida de un bloque finally, que se ejecuta sin
importar si se ha completado con éxito o no el bloque try.
try {
statements;
} catch (ExceptionClass e) {
statements;
} finally {
statements;
CODIGO: CIGI005GI
PAGINA:16 de 18
APROBADO: R.C.G.
FECHA: 2012/06
6.9.10 Líneas en Blanco

Las líneas en blanco mejoran la lectura separando secciones de código que están relacionadas
lógicamente.
Siempre se deberían usar dos líneas en blanco en las siguientes circunstancias:

 Entre secciones de un fichero fuente
 Entre definiciones de clases e interfaces
Siempre se debería usar una línea en blanco en las siguientes circunstancias:

 Entre métodos
 Entre las variables locales de un método y su primera sentencia
 Antes de un bloque de comentarios o un comentario simple
 Entre secciones lógicas dentro de un método para mejorar su lectura
6.9.11 Espacios en Blanco

Utilizar espacios en blanco bajo las siguientes circunstancias:
 Una palabra clave seguida por un paréntesis tiene que ser separado por un espacio en
blanco.
 Tiene que aparecer un espacio en blanco después de coma en una lista de argumentos.
 Todos los operadores binarios excepto “.” tienen que separarse de sus operandos por
espacios.
 Los espacios en blanco nunca deben de separar los operandos de los operadores sumarios
tales como (“++”) y decremento(“--”).
 Las expresiones en una instrucción for tienen que separarse por un espacio en blanco.
 Los cast tienen que ser seguido por un espacio en blanco.
 Ejemplos:
A += c + d;
A = (a + b) / (c * d);
while (d++ = s++){

n++;
}
printSize(“size is ” + foo + “\n”);
for (expr1; expr2; expr3)
myMethod((byte) aNum, (Object) x);

myMethod((int) (cp + 5), ((int) (i + 3))
+ 8);
6.10 Reportes
En el desarrollo de reportes tener en cuenta lo siguiente:
 Se incluira el logotipo de CAASA en la esquina superior izquierda.
 Se colocara el titulo del reporte en la parte superior centrado.
 Se colocara la fecha en la que se obtiene el reporte en la esquina inferior izquierda.
 Se colocara la paginación en la esquina inferior derecha.
CODIGO: CIGI005GI
PAGINA:17 de 18
APROBADO: R.C.G.
FECHA: 2012/06
7. SEGURIDAD Y SALUD OCUPACIONAL

No aplicable.
8. MEDIO AMBIENTE
No aplicable.
9. OBSERVACIONES
No aplicable.
10. ANEXOS
10.1 Formato para el control de cambios en la documentación
CODIGO: CIGI005GI
PAGINA:18 de 18
APROBADO: R.C.G.
FECHA: 2012/06
ANEXO 10.1
FORMATO PARA CONTROL DE CAMBIOS EN LA DOCUMENTACIÓN
CÓDIGO : CIGI005GI
REGISTRO PARA CONTROL DE LOS REVISIÓN :1
CAMBIOS EN LA DOCUMENTACIÓN APROBADO : RCG
FECHA : 2011/08
PÁGINA : 18 DE 18
TIPO
DE NUEVA FECHA AGREG OMIT MODIFIC
CAMBI REVISIÓ NUEVA OBSERVACIONES A E A
O N REVISIÓN Descripción de la Naturaleza del Cambio
Corrección de Responsables: Página 2, de “Jefe de

TC3 1 11/08 Desarrollo Informático” a “Subgerente de Desarrollo
Informático” y se retira el Jefe de Informática de Sede

Se recibe observación de que todo cambio se debe de
TC6 2 11/12/2011 mostrar en letras negritas en cursiva, asi que se realiza
la modificación según observación

06/12/201 Se modifica denominaciones para trabajar con
TC6 3 2 SAP

Leyenda del Tipo de Cambio

TC1.- Modificaciones del Objetivo del Procedimiento
TC2.- Modificaciones del Alcance del Procedimiento
TC3.- Modificaciones de las Responsabilidades en el Procedimiento
TC4.- Modificaciones en los Documentos de Referencia
TC5.- Modificaciones en las Definiciones Utilizadas en el Procedimiento
TC6.- Modificaciones en las Descripciones en el Procedimiento
TC7.- Modificaciones en temas de Seguridad en el Procedimiento
TC8.- Modificaciones en temas de Medio Ambiente en el Procedimiento
TC9.- Modificaciones en las Observaciones del Procedimiento
TC10.- Modificación de algún Anexo en el Procedimiento
TC11.- Modificaciones Por Cambios en la Codificación y/o Titulo del Procedimiento
TC12.- Modificaciones por Errores Ortográficos en el Procedimiento
TC13.- Modificaciones en las Especificaciones Técnicas de las Hojas de Proceso

Estandares de Desarrollo de Programacion en Java

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Estandares de Desarrollo de Programacion en Java

Cargado por

Copyright:

Formatos disponibles

CODIGO: CIGI005GI

NOMBRE DEL DOCUMENTO:

INSTRUCCIÓN DE ESTÁNDARES DE CODIFICACIÓN

1 TATIANA FLORES ALECXY DIAZ RAFAEL CACERES 2011/08

3.1 Gerente de Informática (GI).- Es el responsable de aprobar la presente instrucción.

4.1 Documentos de Referencia: ISO 9001:2000 Requisito 4.2.3

4.2 Documentos de Consulta: Manual de Gestión de Calidad

Los ficheros de más de 2000 líneas deberían evitarse.

6.1.1 Nombrado de Aplicaciones (Proyecto)

Tipo de Reglas de Nombrado Ejemplos

6.1.2 Nombrado de paquetes

Tipo de Reglas de Nombrado Ejemplos

6.1.3 Nombrado de clases

Tipo de Reglas de Nombrado Ejemplos

6.1.4 Nombrado de interfaces

Tipo de Reglas de Nombrado Ejemplos

Tipo de Reglas de Nombrado Ejemplos

6.1.6 Nombrado de variables

Tipo de Reglas de Nombrado Ejemplos

A continuación se describen los tipos de datos que maneja el lenguaje Java:

La sintaxis para el nombramiento de variables debe seguir el siguiente patrón:

prefijo-tipo-varible + prefijo-ambito + ‘_’ + NombreDescriptivo

6.1.6.1 Prefijos para tipo de variable:

Prefijo Tipo de Variable

6.1.6.2 Prefijos de ámbito:

6.1.6.3 Nombre Descriptivo:

6.1.7 Nombrado de constantes

Tipo de Reglas de Nombrado Ejemplos

6.1.8 Nombrado de Archivos JSP

Tipo de Reglas de Nombrado Ejemplos

6.2Ficheros Fuente Java

Descripción Contiene breve descripción del propósito de la clase

Por cada método colocar el siguiente bloque de comentarios

Método Nombre de método

6.4Sentencias Package e Import

El nombramiento de paquetes debe seguir los siguientes lineamientos:

6.5Declaraciones de Clase e Interface

Parte de la Clase/Interface Notas

 Romper antes de un operador

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

// IDENTACION RECOMENDADA a 8 espacios, para evitar muy poca profundidad

La ruptura de líneas de sentencias if generalmente usará la regla de 8-espacios. Por ejemplo:

//NO USAR ESTA IDENTACION

// USAR ESTA IDENTACION

//O USAR ESTA IDENTACION

Los comentarios de documentación pueden ser extraídos a archivos HTML utilizando la

 Comentarios de línea simple(/*…*/): Se usarán para comentarios cortos (de menos de 30

 Comentarios trainling(/*…*/): Comentarios muy breves (de no mas de 15 caracteres) sobre

Si más de un comentario aparece en un bloque de código, se tiene que identar éstos al

6.7.2 Comentarios de Documentación

 Este tipo de comentarios tienen que aparecer justo antes de la declaración.

Las convenciones para las declaraciones Java son las siguientes:

6.8.1 Declaración de clases e interfaces

 No utilizar espacios entre el nombre de un método y el paréntesis que inicia la lista de

6.8.2 Declaración de instrucciones

 Cada linea tiene que contener solo una instrucción. Ejemplo:

6.8.3 Declaraciones de Clases e Interfaces

6.9.2 Sentencias Compuestas

6.9.3 Sentencias de Retorno

6.9.4 Sentencias if, if-else, if else-if else

6.9.5 Sentencias for

6.9.6 Sentencias while

Una sentencia while debería tener la siguiente forma:

Una sentencia while vacía debería tener la siguiente forma:

 Comentarios de línea simple(/…/): Se usarán para comentarios cortos (de menos de 30

 Comentarios trainling(/…/): Comentarios muy breves (de no mas de 15 caracteres) sobre