Estand HIP INTG Programacion

PP RR II VV AA DD OO

VVVEEERRRSSSIIIÓÓÓNNN 222...222000 FECHA:05/06/2009

ESTÁNDAR DE PROGRAMACIÓN

Página 1-1/32

NOTA: La información contenida en este documento no puede ser duplicada, publicada o copiada sin permiso escrito de HIPER S.A.

ESTÁNDARES DE PROGRAMACIÓN

HIPER S.A.

VERSIÓN 2.00




Página 2/32


Rol Autor Fecha

Preparado por: Analista de Procesos Mauro Rojas 05 de junio de 2009

Revisado por: Encargada de Procesos Susana De la Cruz 05 de junio de 2009

Aprobado por: Gerente de Desarrollo de Software Álvaro Chavez

Resumen :

Procedimiento para estándares de programación en el área de desarrollo, cubre BD, Visual

Basic, Visual C++ y Java.

EVOLUCIÓN DEL DOCUMENTO

Versión Fecha Autor Evolución

Draft 23/05/00 Achavez Documento de trabajo, primera versión

1.00 09/07/03 Achavez Simplificación, inclusión de tablas, normas de VB Bmatic2

1.10 29/11/05 Ccardenas Revisión y modificaciones de estándares de Java.

1.20 19/12/05 Ccardenas Modificación de declaración de controles GUI en los estándares de java

1.30 29/05/07 Scruz Unificación de documentos (java y visual)

1.40 07/07/08 Mrojas Refinamiento de los estándares de Programación.

2.00 11/07/08 Mrojas Incorporación de observaciones de validación.

2.10 07/04/09

Mrojas, Bguerra, Jwong, Jhuaman

Unificación de los prefijos de las variables según el tipo de dato.

Descripción de nomenclatura de objetos de base de datos.

2.20 05/06/09 Mrojas

Modificación en la ubicación del bloque de comentarios en los archivos fuentes en Java.

Modificación en la ubicación de los ejemplos de listados en la sección 8.




Página 3/32


CONTENIDO

1 INTRODUCCIÓN...............................................................................................5

1.1 OBJETIVO......................................................................................................5 1.2 AUDIENCIA ....................................................................................................5 1.3 DOCUMENTOS DE REFERENCIAS ..............................................................5

2 CRITERIOS GENERALES DE CODIFICACIÓN ...............................................6

3 CRITERIOS GENERALES PARA BASE DE DATOS.......................................7

3.1 TABLAS..........................................................................................................7 3.2 CAMPOS ........................................................................................................7 3.3 OBJETOS DE DATOS....................................................................................8

4 CONVENCIONES GENERALES DE ABREVIACIÓN.......................................9

4.1 TIPO DE DATOS ............................................................................................9 4.2 CONTROLES..................................................................................................9

5 PROGRAMACION EN VISUAL BASIC ..........................................................10

5.1 GENERALIDADES .......................................................................................10 5.2 COMENTARIOS ...........................................................................................10 5.3 CONVENIOS DE NOMBRES........................................................................11 5.3.1 TIPOS DE DATOS...................................................................................11 5.3.2 CONTROLES ..........................................................................................11 5.3.3 COMPONENTES.....................................................................................12 5.3.4 OTRAS CONVENCIONES ......................................................................13 5.3.5 OBJETOS DE BASE DE DATOS............................................................13 5.3.6 NOMBRES DE CONSTANTES ...............................................................13

5.4 OPERADORES.............................................................................................14

6 PROGRAMACION EN C++.............................................................................15

6.1 COMENTARIOS ...........................................................................................15 6.2 CONVENCIONES DE NOMBRES ................................................................16 6.2.1 NOMBRES DE VARIABLES Y FUNCIONES ..........................................16 6.2.2 TIPO PREFIJO ........................................................................................16 6.2.3 NOMBRE.................................................................................................17

6.3 CONSIDERACIONES PARA EL ESTILO DE CODIFICACIÓN. ....................18

7 PROGRAMACION EN JAVA..........................................................................19

7.1 GENERALIDADES .......................................................................................19 7.2 ORGANIZACIÓN DE LOS ARCHIVOS.........................................................19 7.3 ARCHIVOS FUENTE....................................................................................19 7.4 TABULACIONES ..........................................................................................20 7.4.1 LONGITUD DE LINEAS ..........................................................................20 7.4.2 JUNTADO DE LINEAS ...........................................................................20

7.5 COMENTARIOS ...........................................................................................20 7.5.1 DELIMITADORES ...................................................................................20 7.5.2 BLOQUES DE COMENTARIO ................................................................21 7.5.3 COMENTARIOS DE UNA LINEA............................................................22




Página 4/32


7.6 CONVENCIONES DE NOMBRADO .............................................................22 7.6.1 TIPOS DE DATOS...................................................................................23 7.6.2 CONVENCIONES DE NOMBRADO DE CONTROLES...........................24 7.6.3 CONVENCIONES DE NOMBRADO DE OBJETOS ................................24

7.7 DECLARACIONES .......................................................................................25 7.7.1 POR LINEA .............................................................................................25 7.7.2 UBICACIÓN ............................................................................................25 7.7.3 INICIALIZACIÓN .....................................................................................25 7.7.4 DECLARACIONES DE CLASES E INTERFACES..................................26

7.8 SENTENCIAS...............................................................................................26 7.8.1 SENTENCIAS SIMPLES .........................................................................26 7.8.2 SENTENCIAS RETURN ..........................................................................26 7.8.3 SENTENCIAS IF- ELSE ..........................................................................27 7.8.4 SENTENCIAS FOR .................................................................................27 7.8.5 SENTENCIAS WHILE .............................................................................27 7.8.6 SENTENCIAS DO- WHILE ......................................................................28 7.8.7 SENTENCIAS SWITCH...........................................................................28 7.8.8 SENTENCIAS TRY- CATCH - FINALY ...................................................29

7.9 ESTILO DE PROGRAMACIÓN RECOMENDADO .......................................29

8 OTROS ESTÁNDARES: .................................................................................31




Página 5/32


1 INTRODUCCIÓN

1.1 OBJETIVO

El presente documento contiene las recomendaciones para el formato y escritura de archivos

fuente, está orientado a los lenguajes de programación Java, C++ y Visual Basic. En general

estas normas o convenciones deben seguirse a menos que expresamente se determine seguir

otras normas en algún proyecto en particular, en este caso las nuevas normas deben estar

descritas dentro de la documentación del proyecto.

El objetivo de las normas es garantizar una fácil lectura de los archivos fuente por parte de

personas diferentes a los programadores originales, del mismo modo facilita la portabilidad de

rutinas entre diferentes proyectos y la integración con librerías de terceros ya que se utilizan

normas que son consideradas estándares de facto o de gran difusión en la industria.

1.2 AUDIENCIA

El presente documento esta dirigido a programadores responsables por el mantenimiento y

desarrollo de los diferentes sistemas, también a las personas involucradas en la revisión de las

fuentes y la determinación de la calidad de los mismos.

1.3 DOCUMENTOS DE REFERENCIAS

Este documento contiene los convenios de nombres usados por los Servicios de Consulta

Microsoft (MCS), y los estándares de Sun Microsystems.




Página 6/32


2 CRITERIOS GENERALES DE CODIFICACIÓN

La codificación debe seguir los siguientes principios generales, algunos de los cuales son

ampliados posteriormente:

• Todos los archivos fuente deben incluir una cabecera indicando el propósito, sistema

e historia de cambios (el historial de cambios no será necesario si se maneja una

herramienta para el control de versiones).

• Todas las declaraciones de variables deben incluir un comentario en línea

describiendo el uso de la variable.

• Cada función debe tener una cabecera indicando el nombre, el propósito, los

argumentos y los valores de retorno.

• Las partes del código complejas deben incluir comentarios aclaratorios en la línea

respectiva.

• Las variables y funciones deben nombrarse de acuerdo a los estándares descritos en

este documento.

• Las entidades deben estar identificadas en clases y la funcionalidad correctamente

encapsulada.

• Para Visual Basic y C++:

o Las funciones deben tener un tamaño manejable, no deberían tener más de

100 líneas en condiciones normales.

o Las funciones deben ser escritas respetando los principios de cohesión y

acoplamiento de programación estructurada.

• Para Java:

o Los métodos deben tener un tamaño manejable, no deberían tener más de 50

líneas en condiciones normales.

o Los métodos deben ser escritas respectando los principios de Programación

Orientada a Objetos (Herencia y Polimorfismo).

o Todos los comentarios de la clase, funciones y variables miembro debe estar

sujeta al estándar JavaDoc.




Página 7/32


3 CRITERIOS GENERALES PARA BASE DE DATOS

El nombre de los objetos usados en la base de datos no debe exceder a 16 caracteres.

3.1 TABLAS

El nombre de la tabla tiene el siguiente formato:

<Acronímico de tabla><nombre de tabla>

Ejemplo: tmTicket

CAMPO LEN DESCRIPCIÓN

Acronímico 2

Existen los sgtes. Tipos: - tm = tabla maestra - tx = tabla de uso del sistema - tp = tabla de proceso - ta = tabla asociativa y relacional. - th = tabla historial Td=dimensional

Nombre de tabla Hasta 14

El nombre de la tabla puede ser de una palabra o compuesta de más de una. En cualquier caso se escribe tipo título la primera con mayúscula y lo que sigue con minúscula.

3.2 CAMPOS

El nombre de los campos tiene el siguiente formato.

<Acronímico del campo><abreviatura de la tabla><abreviatura de la tabla>

Ejemplo: fTkGenerado

CAMPO LEN DESCRIPCIÓN

acronímico 1

Los acronímicos representan la función del campo más no el tipo de dato dado que todos son de tipo STRING. Existen los siguientes. Tipos: - c = campo código - d = campo descriptivo - h = campo hora - f = campo fecha - n = campo número

Abreviatura de tabla

Hasta 4 La abreviación puede ser las iniciales del nombre de la tabla. Cuando este coincide con otra tabla, se puede usar una abreviación compuesta hasta 4 caracteres.

Nombre del campo

En función al anterior

Es la descripción del campo y tiene un tamaño tal, que el nombre completo del campo no debe exceder los 16.




Página 8/32


3.3 OBJETOS DE DATOS

TIPO DE DATO ABV OBSERVACIÓN

Store Procedure SP_ Todo en mayúscula. Dos o tres palabras descriptivas separadas por el carácter underline (_)

Trigger TRG_ Todo en mayúscula. Dos o tres palabras descriptivas separadas por el carácter underline (_)

Funciones FUNCT_ Todo en mayúscula. Dos o tres palabras descriptivas separadas por el carácter underline (_)

Indices IX_ Todo en mayúscula. Dos o tres palabras descriptivas separadas por el carácter underline (_)




Página 9/32


4 CONVENCIONES GENERALES DE ABREVIACIÓN

La abreviatura de la los tipos de datos generales para los lenguajes de programación que se

especifican en este documento, se listan en la siguiente tabla:

4.1 TIPO DE DATOS

Tipo de Datos Abreviatura/Prefijo Ejemplo String s sDescripcionTicket boolean is/can/has1 isEstadoRegistro double d dTotalTickets Int, integer i iContTicket float f fPromedio char c cPrefijoTable long l lResultadoOperacion short sh List, ArrayList lst lstProveedores Array arr arrRecibosfacturados Date, Fecha dat datGeneracionTicket

4.2 CONTROLES

Tipo de Controles Abreviatura/Prefijo Ejemplo CheckBox chk chkEstadoTicket ComboBox cmb cmbAgencia Label lbl lblNombreAgencia

TextField, Textbox txt txtNombreAgencia Button btn btnAceptar Panel pan panCliente Imagen img imgAyudaAgencia RadioButton rdb rdbCargaOnLine Listas, Listbox lta ltaTipoVentanilla

ProgressBar pgb prgCargaInicio

Timer tmr tmrTiempoRetardoEntreTicket

Formulario frm frmPersona

Groupbox grp gprDatosCliente

Nota: Los tipos de datos y controles particulares a cada lenguaje se listan en las secciones

siguientes.

1 El prefijo va a depender del tipo de condicional que se quiera evaluar por ejemplo: Si se quiere crear una variable condicional para determinar si un valor es de tipo fecha se debería establecer el siguiente nombre “isTipoFecha”. Si se quiere crear una variable condicional para determinar si un registro puede ser almacenado se debería establecer el siguiente nombre “canGrabarReg”. Si se quiere crear una variable condicional para determinar si un valor es contenido en una cadena se debería establecer el siguiente nombre “hasCodigo”.




Página 10/32


5 PROGRAMACION EN VISUAL BASIC

5.1 GENERALIDADES

El lenguaje Visual Basic está documentado en función a las convenciones de codificación

establecidas por Microsoft y las buenas prácticas adquiridas en el desarrollo de nuestros

sistemas.

Se sugiere tomar en consideración las siguientes recomendaciones:

� Use la Opción Explícita. Declare todas las variables para guardarlas en tiempo de

programación para reducir el número de errores causados por tipos (por ejemplo,

aUserNameTmp versus sUserNameTmp versus sUserNameTemp). En el diálogo de

Opciones del Entorno, configure la Declaración de Variable requerida a Sí.

� Guarde archivos como texto ASCII. Guarde archivos, formularios (.FRM) y módulos

(.BAS) como texto ASCII para facilitar el uso de la versión de los sistemas de control y

minimizar el daño que puede ser causado por la descomposición del disco.

5.2 COMENTARIOS

Todos los archivos fuente contendrán un título en la parte de arriba del archivo. Este título

seguirá el formato del ejemplo que sigue.

'Author: ' Wei Hua August 20, 1999 ' ' Revision History: ' Who When What ' -------- -------- --------------------------------- ' Wei Hua 08-20-99 created Todos los procedimientos y funciones deberían comenzar con un comentario breve que describa las características funcionales de la rutina (lo que hace). ' ParseMultistring ' ' converts C++ type multistring to VB type array of strings ' and reports the number of strings in array ' ' assumptions: ' ' first parameter actually contains a good format multistring ' no checking is done for bad format, empty string, or null pointer ' ' arguments: ' ' strMultistring - supplies the multistring to be converted, ' whose format is concatenated null terminated strings, with an




Página 11/32


' additional null terminator at the end of the last string ' ' intReaderCount - returns the number of strings in the array ' note that an array with 4 strings will have indexes 0 to 3 ' ' return value: ' ' an array of strings - can contain one empty element if no readers found ' indirectly through second parameter, the count of strings in the array '

5.3 CONVENIOS DE NOMBRES

5.3.1 TIPOS DE DATOS

Las variables deben declararse lo mas descriptivo posible y de tipo camello, es decir cuando es

compuesta, la primera letra de cada palabra es mayúscula y el resto minúscula.

TIPO DE DATO ABV EJEMPLO

Object Obj ObjTicket

Variant Var VarOpcionesDePantalla

NOTA: Cualquier otra variable que no figure en la lista, no debe utilizarse.

OTROS ABV EJEMPLO

Variables públicas

La abreviación no cambia, pero el título de la variable es todo con mayúscula y si es compuesta va separado por un carácter “anderlyng” Ejemplo: sNOMBRE_ACTUAL_VENTANILLA

Constantes

Debe ser descrita todo con mayúscula y lo más descriptivo posible: Ejemplo: OPCION_ACEPTAR = 1 OPCION_RECHAZAR = 2

5.3.2 CONTROLES

Los controles deben declararse lo mas descriptivo posible y de tipo camello, es decir cuando es


TIPO DE CONTROL ABV EJEMPLO

CommandBottom Cmd CmdAceptar

DriveListBox Drv DrvUnidadC




Página 12/32


DirListBox Dir DirBaseDeDatos

DTPicker Dtp DtpFechaIngreso

ImageList Iml ImlListaAgencia

Line Lin LinSeparadorA

ListView lvw LvwCliente

OptionButton opt optSexoCliente

Picture pic picFondoPantalla

RichTextBox rtb rtbObservacionGeneral

StatusBar stb stbPantallaPrincipal

SSTab sst sstOpcionTicketera

Toolbar Tlb tlbPantallaPrincipal

TreeView tvw tvwMenuPrincipal

Menu mnu mnuArchivo

WebViewer web webAyudaAgencia

Link lnk lnkAsientoContable

Listview lvw lvwTipoCuenta

Datagridview dgw dgwDescripcion

Datatimepicker dtp dtpTime

Groupbox grp gprDatosCliente

MaskTextbox msk mskIngreso

Picturebox pic picRegion

Statusstrip stb

Tabcontrol tab

Webbrowser web

5.3.3 COMPONENTES

Los componentes deben declararse lo mas descriptivo posible y de tipo camello, es decir

cuando es compuesta, la primera letra de cada palabra es mayúscula y el resto minúscula.

TIPO DE COMPONENTE

ABV EJEMPLO

ADOConnection cnn CnnBMatic

ADORecordset rec RecAgencia

Collections Cll cllDetalleProgrmacion Clase Maestra (servidor)

CM_ CM_Cliente

Clase Control (servidor)

CC_ CC_Ventanilla

Clase de usuario (cliente)

cls ClsCliente

Archivos HTML htm htmAyudaAgencia




Página 13/32


NOTA: Cualquier otro componente que no figure en la lista, debe utilizarse la abreviación de

objeto genral (obj)

5.3.4 OTRAS CONVENCIONES

Otros Abv Ejemplo

Procedure o Function privado

V_ v_BuscarSiguienteTicket

Procedure o Function público

B_ b_ListarAgencia

5.3.5 OBJETOS DE BASE DE DATOS

Prefijo Tipo de Objeto Ejemplo Db ODBC Database dbAccounts Ds ODBC Dynaset object dsSalesByRegion Fdc Field collection fdcCustomer Fd Field object fdAddress Ix Index object ixAge Ixc Index collection ixcNewAge Qd QueryDef object qdSalesByRegion qry (sufijo) Query (ver NOTA) SalesByRegionQry ss Snapshot object ssForecast tb Table object tbCustomer td TableDef object tdCustomers

NOTA: Usando un sufijo para consultas permite a cada consulta ser ordenado con su tabla

asociada en diálogos de Microsoft Access (Agregar tablas, Listar tablas instantáneas).

5.3.6 NOMBRES DE CONSTANTES

El cuerpo de los nombres constantes debería ser UPPER_CASE con subraya (_) entre las

palabras. Aunque las constantes estándar de Visual Basic no incluyen información Húngara,

los prefijos como i, s, g, y m pueden ser muy útiles para la comprensión del valor y alcance de

una constante. Para nombres constantes, seguir las mismas reglas como las variables. Por

ejemplo:

<mnUSER_LIST_MAX ' Límite de ingreso máximo para la lista de Usuarios (valor entero, local al módulo) gsNEW_LINE ' Nueva línea de cadena de caracteres (global a la




Página 14/32


aplicación entera)

5.4 OPERADORES

Siempre usar un ampersand (&) cuando se concatenan cadenas, y usar el signo más (+)

cuando trabajamos con valores numéricos. Usar un signo más (+) con valores no numéricos,

puede causar problemas cuando operamos sobre dos variantes. Por ejemplo:

vntVar1 = "10.01" vntVar2 = 11 vntResult = vntVar1 + vntVar2 ' vntResult = 21.01 vntResult = vntVar1 & vntVar2 ' vntResult = 10.0111




Página 15/32


6 PROGRAMACION EN C++

6.1 COMENTARIOS

Todos los archivos fuente contendrán un título en la parte de arriba del archivo. Estos

elementos son:

Elemento DESCRIPCIÓN File Nombre del archivo. Summary Resumen de la implementación del archivo fuente. History Historial de cambios, debe seguir la siguiente estructura:

<Fecha dd-mm-yy>-<nombre programador>-<modificación> El nombre del programador deberá ser el nombre de red.

Copyright Copyright © HIPER S.A.

Este título seguirá el formato del ejemplo que sigue.

/*+========================================================================== File: APPUTIL.CPP Summary: Implementation file for the general application utility classes and functions offered by the APPUTIL library. For a comprehensive tutorial code tour of APPUTIL's contents and offerings see the tutorial APPUTIL.HTM file. For more specific details see the comments dispersed throughout the APPUTIL source code. History: 8-28-97: atrent - Revised (based on WINHLPRS by stevebl). (Nombre programador, modificacion) ---------------------------------------------------------------------------- This file is part of the Microsoft COM Tutorial Code Samples. Copyright (C) 1995 - 2000 Microsoft Corporation. All rights reserved. This source code is intended only as a supplement to Microsoft Development Tools and/or on-line documentation. See these other materials for detailed information regarding Microsoft code samples. ==========================================================================+*/

Adicionalmente cada función debe tener un encabezado con la siguiente información:

Elemento DESCRIPCIÓN Function Nombre de la función. Summary Resumen de la implementación de la función. Args Describe los parámetros de entrada y salida de la función, deberá

seguir la siguiente estructura: <tipo de parámetro> <Nombre parámetro> <Descripción Parámetro> El tipo de parámetro puede ser: [in], [out] o [in/out]

Returns Describe el retorno de la función. La descripción de la función seguirá el formato del siguiente ejemplo.




Página 16/32


/*+========================================================================== Function: AnsiToUc Summary: Convert an ANSI 'multibyte' string into a UNICODE 'wide character' string. Args: [in/out] LPSTR pszAnsi Pointer to a caller's null terminated input ANSI string. [in] LPWSTR pwszUc Pointer to a caller's output UNICODE wide string buffer. [out] int cch Size of pwszUc in number of wide characters. Must be greater than 0. Returns: HRESULT Standard result code. NOERROR for success. ==========================================================================+*/

6.2 CONVENCIONES DE NOMBRES

6.2.1 NOMBRES DE VARIABLES Y FUNCIONES

Los nombres de variables y funciones siguen el ejemplo de la Notación Húngara para C. La

mayoría de los programadores no familiarizados con la experiencia de la Notación Húngara

tienen un poco de incomodidad con el concepto al principio, pero una vez que el concepto se

vuelve parte de su rutina normal ellos encuentran que esto proporciona una mejora significante

en la productividad, especialmente en el mantenimiento y perspectiva del perfeccionamiento.

Un nombre Húngaro se construye como sigue:

nombre_variable ::= [tipo_prefijo] [nombre_descriptivo]

nombre_función :: = [prefijo_tipo_retorno] [nombre_descriptivo]

6.2.2 TIPO PREFIJO

El prefijo para todos los nombres de variables y funciones se adherirán al siguiente esquema.

Esto pone información útil acerca de un nombre de variable o función, incluso cuando se vieran

fuera del contexto. El prefijo designa el tipo (para las variables) o el tipo de retorno (para las

funciones), y cuando es seguido por unos nombres significativos, rinde una descripción

bastante completa del propósito de la variable o función.

DESIGNACIÓN PREFIJO COMENTARIOS Global g pointer p enum e structure st unsigned u short integer (2 bytes) n ‘n’ se usa estrictamente para los enteros

cortos




Página 17/32


character n byte by bitfield bf constant (C++ equivalent of #define)

k

non-null-terminated character string

“s”

C-style null-terminated character string

sz

En ciertos casos, estos prefijos pueden estar combinados. Por ejemplo, un nombre de variable

tipo carácter no establecido se prefijaría por ‘u’ y ‘c’. El orden de composición generalmente

sigue el orden de la tabla de arriba, y comunica información importante.

Como ejemplos:

alDailyScanQuantityTotalAllLines[10] Un arreglo de 10 enteros largos, cada uno de los cuales representa la cantidad total de exámenes reunidos para todas las líneas en un día dado.

szCustomerName[32]; Cadena de caracteres que terminan en null contienen 31 bytes paras el nombre del cliente (más 1 byte para el null)

PstStoreInformation Un indicador para estructurar ‘stStoreInformation’

Note el caso especial para uniones: en lugar de prefijar el nombre de la variable con un tipo de

dato, la palabra “unión” debería ser usado como el único tipo_prefijo o, alternativamente,

pudiera aparecer en otra parte del nombre de la variable, con tal de que el tipo_prefijo sea nulo.

6.2.3 NOMBRE.

Este es el componente principal de un nombre Húngaro para una variable o función. Esto

simplemente describe el uso o propósito principal de una variable o de una función. Esto

típicamente consiste de una o más palabras compuestas de sólo caracteres alfabéticos,

concatenados juntos, sin subrayas. La primera letra de cada palabra comprende el

nombre_descriptivo que siempre se capitaliza, y las letras restantes de cada palabra son en

minúscula.

Las abreviaciones son aceptadas cuando son completamente inequívocas y describen

términos generalmente usados a través de muchas aplicaciones. Esto se deja a la prudencia

del desarrollador para usar las abreviaciones; generalmente esto se disuelve a menos que ellos

puedan tener claramente un solo significado. Los ejemplos de abreviaciones aceptables son

las que siguen:

ABREVIACIÓN DESCRIPCIÓN




Página 18/32


Addr Dirección (de un cliente, no de estructura o variable C) Amt Suma, importe Misc Misceláneo Msg Mensaje Nbr Número Pct Porcentaje Qty Cantidad

6.3 CONSIDERACIONES PARA EL ESTILO DE CODIFICACIÓN.

Para equilibrar el estilo de codificación entre creatividad y entendimiento es necesario

establecer puntos de referencia universales basados en las buenas prácticas difundidas en la

codificación, las cuales se listan a continuación:

• Todos los nombres de variables y funciones utilizarán la Notación Húngara como se

describió anteriormente.

• Los corchetes siempre serán alineados verticalmente.

• La alineación vertical de los corchetes debería estar debajo de la apertura de la palabra

importante o con la apertura del bloque condicional (paréntesis).

• La alineación del código será consistente a lo largo de todo el archivo.

• El código debería ser comentado libremente con comentarios significativos.

• Para el código oscuro o “engañoso”, cuya función no es fácilmente clara o que logra

una tarea de la forma en que otra lo haría bajo las prácticas normalmente aceptadas

debido a alguna condición particular, una explicación completa del algoritmo se

acompañará por una explicación de por qué el acceso más comúnmente aceptado no

fue tomado. Esto habilitará a otros desarrolladores a intentar perfeccionar o clarificar la

lógica a tiempo para algún punto posterior, si esa optimización o clarificación

produjeran un problema que el desarrollador original buscó evitar especialmente.

• Los cambios en el código son típicamente más fáciles de ejecutar por el desarrollador

original. Los cambios al código de otro desarrollador deberían adherirse al estilo de ese

programador (alineación de los corchetes del bloque, etc.) si todavía es su

responsabilidad.

• El código debería estar conformado por el entorno en el cual se editará o mostrará.

Por ejemplo, para el código que se mantendrá usando los términos ASCII, las líneas

del código deberían ser de 80 caracteres o menos siempre que sea práctico.




Página 19/32


7 PROGRAMACION EN JAVA

7.1 GENERALIDADES

El lenguaje Java está documentado en función a las convenciones de codificación establecidas

por Sun Microsystems y las buenas prácticas adquiridas en el desarrollo de nuestros sistemas.

Los IDE’s (Integrated Development Environment) establecidos en nuestra institución son

NetBeans y JDeveloper.

Para ambos casos es indispensable el uso del Visual SourceSafe como controlador de

versiones.

7.2 ORGANIZACIÓN DE LOS ARCHIVOS

Separar las secciones del archivo mediante espacios en blanco, una sección está conformada

por el bloque de comentario seguido del código comentado, esto permite identificar fácilmente

cada sección. Evitar archivos mayores a 2000 líneas.

7.3 ARCHIVOS FUENTE

Cada archivo fuente contiene una única clase publica o interfase. Cuando las clases privadas y

las interfaces son asociadas a una clase pública, éstas deberán colocarse en el mismo archivo

fuente de la clase pública. La clase pública deberá ser la primera clase o interfaz en la fuente.

Los archivos fuente en Java deben seguir la siguiente estructura:

ELEMENTO DESCRIPCIÓN Nombre del Paquete Nombre del paquete donde será incluido el archivo. Librerías a importar Nombre de las librerías necesarias para implementar el

código fuente. Bloque de comentario. Describe la información básica del archivo, esta

información debe ser suficiente y entendible para futuras actualizaciones y modificaciones del archivo. Esta sección incluye la descripción de las clases y métodos según el nivel.

Declaración de Clases e Interfaces

Inicio de la especificación del código.

Nota: Se colocará como comentario el Nombre del archivo en la cabecera.

Por ejemplo:

/* Customer.java */ package view;




Página 20/32


import java.util.*;

/** * <Bloque de comentario de la clase> * @version 1.0 02 febrero 2004 * @author jprieto * Copyright © HIPER S.A. */ public class Customer {.......}

7.4 TABULACIONES

7.4.1 LONGITUD DE LINEAS

Evitar líneas superiores a los 80 caracteres de largo aproximadamente, para facilitar una mejor

lectura.

7.4.2 JUNTADO DE LINEAS

Cuando una expresión no se ajuste a una sola línea, aplicar las siguientes acciones:

• Separarla después de una coma.

• Separarla antes de un operador.

Ejemplo:

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

Ejemplo para el caso de operadores aritméticos:

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

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

7.5 COMENTARIOS

7.5.1 DELIMITADORES

Son los signos que agrupan los caracteres relacionados al comentario.

ELEMENTO DECLARACIÓN DESCRIPCIÓN

/** Indica que el comentario está relacionado a una clase, interfaz, constructor o método.

/* Signo global de inicio del comentario.

Inicio de Comentario

* Inicio de una nueva línea de comentario contenido en un bloque.




Página 21/32


// Delimitador de una sola línea.

Finalización de Comentario */ Signo global de fin del comentario

Nota: Es de gran importancia recordar que los delimitadores “/** */” generalmente son

aplicados para los comentarios genéricos y son explicativos (son indispensables para

documentar las clases según el Javadoc), mientras que los delimitadores “/* */ “ y “//”

generalmente son aplicados para los comentarios propios a codificación (No se muestran en al

Javadoc).

7.5.2 BLOQUES DE COMENTARIO

Son usados para proporcionar descripciones de archivos, métodos. Deben ser usados al

principio de cada archivo (posterior a la importación de los paquetes) y antes de cada método.

Pueden también ser usados dentro de métodos. Deberían ser precedidos por una línea en

blanco para separarlo del código. Deben tener un asterisco al principio de cada línea.

Los comentarios de los archivos deben seguir el siguiente esquema:


Descripción de Clase

Describir en esta sección en forma global la especificación de la clase o interfaz.

Número de Versión @version <número> <dd

mes aaaa>

Versión del código fuente. Está compuesta por el número de la versión del código y la fecha de modificación. dd: Número de día. mes: Nombre del mes. aaaa: año.

Autor @author <nombre autor> Nombre del programador que generó o alteró el código. El nombré será el usuario de red.

Copyright Copyright © HIPER S.A.

Indica que el código fuente es propiedad de HIPER S.A.

Los comentarios de los métodos deben seguir el siguiente esquema:


Descripción del método ---

Describe globalmente la funcionalidad que implementa el método.

Parámetros @param <param1…, param n>

Cita los parámetros necesarios para la ejecución del método.

Valor de retorno @return <valor1…, valor n >

Cita los valores de retorno del método. no se puede usar en constructores o métodos "void".

Referencias @see <ref1…, refn.> Referencia a otros métodos o




Página 22/32


clases.

@deprecated

Indica que la función o clase es antigua y que no se recomienda su uso porque posiblemente desaparecerá en versiones posteriores.

Complementos

@throws, @exception Excepción lanzada por el método

Ejemplo:

A nivel de Clase:

/** * Una clase para representar círculos situados sobre el plano. * Cada círculo queda determinado por su radio junto con las * coordenadas de su centro. * @version 1.00 02 febrero 2004 * @author jprieto * Copyright © HIPER S.A. */

A nivel de método:

/** * Crea un círculo a partir de su origen su radio. * @param x La coordenada x del centro del círculo. * @param y La coordenada y del centro del círculo. * @param r El radio del círculo. Debe ser mayor o igual a 0. */ public Circulo(double x, double y, double r) { this.x=x; this.y = y; this.r = r; }

7.5.3 COMENTARIOS DE UNA LINEA

Los comentarios cortos pueden aparecer en una línea al nivel de código que sigue. Se utilizará

el signo “//”.

if (condition) { // comentario de una sola línea... .... }

7.6 CONVENCIONES DE NOMBRADO

A continuación se presentan las siguientes reglas que deben ser seguidas:




Página 23/32


TIPO DE IDENTIFICADOR

REGLAS EJEMPLO

Clases Deben ser sustantivos, primera letra mayúscula. Deben ser descriptivos.

class Customer

Interfaces Deben ser nombrados como las clases

interface Impuesto

Métodos

Deben ser verbos. Primera letra en minúscula, y la Segunda letra intermedia Mayúscula.

getListaClientes

Variables locales, miembros y temporales

Deben comenzar con el prefijo del tipo de dato2, seguido del nombre con la primera letra en mayúscula de cada palabra. Deben ser cortas y expresar su intención de uso.

String sNombreCliente

Constantes

Deben ser declaradas todas en mayúscula. Si es necesario usar _ para nombres compuestos.

int MIN_PRICE = 4

7.6.1 TIPOS DE DATOS

Los tipos de datos genéricos se describen en la sección 4.1 del documento, a continuación se

listan algunos de los tipos de datos propios al lenguaje:

TIPO DE DATO ABREVIATURA/PREFIJO EJEMPLO

Hashtable ht htFormatoInterno

SimpleDateFormat sdf sdfFormatoFecha

HashMap map mapFormato

Para el manejo de base de datos se tienen los siguientes tipos de datos mas usados:

TIPO DE DATO ABV EJEMPLO

Connection Con conBDHCenter2

Statement st stSentencia

ResultSet rs rsResultadoQuery

PreparedStatement pst pstSentencia

ResultSetMetaData rsmd rsmdDataTabla

CallableStatement calSt calStSentenciaSP

Para las constantes se tiene:

TIPO DE IDENTIFICADOR

REGLAS EJEMPLO

2 Referirse a la sección 4 del documento para ver la lista de prefijos genéricos.




Página 24/32


Constantes

Deben ser declaradas todas en mayúscula. Si es necesario usar _ para nombres compuestos.

int MIN_PRICE = 4

7.6.2 CONVENCIONES DE NOMBRADO DE CONTROLES

Los controles deben declararse lo mas descriptivo posible y de tipo camello, es decir cuando es


TIPO DE CONTROL ABREVIATURA/PREFIJO EJEMPLO

Formulario frm frmVentanilla

Line lin linSeparadorA

Option opt optSexoCliente

Menu mnu mnuCrear

Table tbl tblCustomers

TextArea tatArea txtAreaComentario

ScrollBar scr scrHorizontal

TextPane txtPan txtPanEditor

Table tbl tblResultados

PasswordField psw pswClave

TabbedPane tbp tbpPropiedades

ToolBar bar barBotones

ScrollPane scp scpContenedor

Tree tre treComercios

SplitPane scp

ToolBar tbr

Tabla Tbl

7.6.3 CONVENCIONES DE NOMBRADO DE OBJETOS

Algunos tipos de objetos propios del lenguaje como las excepciones, siguen una misma notación:

CLASE NOMBRE DE OBJETO

Exception e

NumberFormatException nfe

IOException ioe

SQLException sqle

ClassNotFoundException cnfe




Página 25/32


7.7 DECLARACIONES

7.7.1 POR LINEA

Se recomienda una declaración por línea con su comentario.

Ejemplo:

int level; // nivel de indentación int size; // tamaño de la tabla

7.7.2 UBICACIÓN

Colocar las declaraciones solo en el principio de los bloques. (Un bloque es cualquier código

entre “{” y “}”.) Ejemplo

void MyMethod() { int int1; // inicio del bloque del metodo if (condition) { int int2; // inicio del bloque del “if” ...

} }

La única excepción de la regla son indexes de for, los cuales en Java pueden ser declarados

en la sentencia for:

for (int i = 0; i < maxLoops; i++) { ...

Por ejemplo no declarar el mismo nombre de la variable en un bloque interno.

int count; ... func() { if (condition) { int count; // EVITAR! ... } ... }

7.7.3 INICIALIZACIÓN

Inicializar las variables locales donde ellas son declaradas.

La única razón para no inicializar una variable es si el valor inicial depende de algún cálculo

que ocurra primero.




Página 26/32


7.7.4 DECLARACIONES DE CLASES E INTERFACES

Al momento de realizar la declaración de las clases e interfaces, tomar en cuenta lo siguiente:

• No establecer espacios entre el nombre de un método y los paréntesis.

• Abrir llaves “{” en el final de la misma línea de la declaración de la sentencia.

• Cerrar llaves “}” al principio de línea a la altura de su correspondiente apertura excepto

cuando esta es una sentencia nula; en dicho caso el signo “}” debe aparecer

inmediatamente después de “{“

• Los métodos deben ser separados por una línea en blanco

Ejemplo:

class Sample extends Object { int ivar1; int ivar2; Sample(int i, int j) { ivar1 = i; ivar2 = j; } int emptyMethod() {} ... }

7.8 SENTENCIAS

7.8.1 SENTENCIAS SIMPLES

Cada línea debe contener por lo menos una sentencia.

Ejemplo:

a = 1;

7.8.2 SENTENCIAS RETURN

Una sentencia return con un valor no debe usar paréntesis al menos que ellas hagan el valor

de retorno mas obvio en alguna forma.

Ejemplo:

return; return myDisk.size(); return (size ? size : defaultSize);




Página 27/32


7.8.3 SENTENCIAS IF- ELSE

Seguir las siguientes reglas:

if (condition) { statements; } if (condition) { statements; } else { statements; } if (condition) { statements; } else if (condition) { statements; } else (condition) { statements; }

7.8.4 SENTENCIAS FOR

Sentencia for deberá tener la siguiente forma:

for (inicializacion; condicion; fin) { sentencias;

}

Ejemplo:

for(int i =0; i<10; i++){ System.out.println(i);

}

7.8.5 SENTENCIAS WHILE

Sentencia while deberá tener la siguiente forma:

while (condition) { sentencias; }

Ejemplo:

while(i<10){ i++;




Página 28/32


}

7.8.6 SENTENCIAS DO- WHILE

Sentencia do while deberá tener la siguiente forma:

do { statements; } while (condition);

Ejemplo:

do { i++; } while (i<10);

Nota: Para las sentencias if-else, for, while, do-while utilizar siempre llaves {}. Evitar las

siguientes formas:

if (condition) //olvidar las llaves statement;

while(x>10) x++;

7.8.7 SENTENCIAS SWITCH

Sentencia switch deberá tener la siguiente forma:

switch (condition) { case ABC:

statements; break;

case DEF: statements; break;

case XYZ: statements; break;

default: statements; break;

}




Página 29/32


7.8.8 SENTENCIAS TRY- CATCH - FINALY

Sentencia try match finaly deberá tener la siguiente forma:

try { statements;

} catch (ExceptionClass e) { statements;

} catch (Exception e2) { statements;

} finaly { statements;

}

Ejemplo:

try{ controlSemana.semana(); System.out.printn("\nNo ha habido error"); } catch (ArrayIndexOutBoundException e){ System.out.println("\nIndice fuera de rango"); } finally{ System.out.println ("\nVuelvo del método semana"); }

7.9 ESTILO DE PROGRAMACIÓN RECOMENDADO

/*Blash.java*/ package java.blah; import java.blah.blahdy.BlahBlah;

/* Descripción de la clase * @version 1.0 02 febrero 2004 * @author jprieto * Copyright © HIPER S.A. */ public class Blah extends SomeClass {

/* <Colocar aquí la descripción detallada de la implementación de la clase>. */

/** <Comentar la documentación de la classVar1> */ public static int classVar1; /**

* <Documentación de los comentarios de classVar2

* en mas de una línea> */ private static Object classVar2;




Página 30/32


/** <Comentar la documentación de instanceVar1> */ public Object instanceVar1;

/** <Comentar la documentación de instanceVar2> */ protected int instanceVar2;

/** <Comentar la documentación de instanceVar3> */ private Object[] instanceVar3; /**

* ...<Documentación del método Blah>... */ public Blah() {

// ..<Describir la implementación del método>... } /**

* ...<Documentación del método doSomething >...... */ public void doSomething() {

// ..<Describir la implementación del método>... }

/**

* ...method doSomethingElse documentación...

* @param someParam descripcion

*/

public void doSomethingElse(Object someParam) {

// ..<Describir la implementación del método>...

}

}


VV VEE ERR RSS SII I ÓÓ ÓNN N 22 2.. . 11 111 1

FECHA:05/06/2009


Página 31/32

NOTA: La inform

ación contenida en este documento no puede ser duplicada, publicada o copiada sin perm

iso escrito de HIPER S.A.

8 OTROS ESTÁNDARES:

TIPO

NOMBRE

DETALLE

EJEMPLO

FRAMEWORK

STRUTS

Struts es una herramienta de soporte para el desarrollo de

aplicaciones Web bajo el patrón MVC bajo la plataforma J2EE

(Java 2, Enterprise Edition).

https://alpha:8443/svn/Ejemplos/trunk/struts

- NuevoContometro.jsp: ejemplo linea 97-100.

- ContometroForm.java.

- ContometroAction.java

ACCESO A

BASE DE

DATOS

DAO

Es un patrón de Acceso a Datos que resuelve el problema de

contar con diversas fuentes de datos (base de datos, archivos,

servicios externos, etc.). Encapsula la forma de acceder a la

fuente de datos.

https://alpha:8443/svn/Ejemplos/trunk/DAO

- DAOFactory.java

- SQLServerDAOFactory.java

- SQLServerComptometerDAO.java: línea 32.

Método: public boolean insert(Comptometer

comptometer)

EDITOR DE

REPORTES

IREPORT

Es una herramienta Editor para construir la estructura visual de

los reportes a implementar se realiza a través de la edición

visual de un xml. Da un soporte visual sobre JasperReports.

https://alpha:8443/svn/Ejemplos/trunk/iReport

- ReporteConsumoContxComercio.jrxml

GENERAR

REPORTES

JASPER

REPORT

Es una herramienta opensource que se compone de un

conjunto de librerías java que facilitan la generación de

reportes en aplicaciones tanto Web como de escritorio.

https://alpha:8443/svn/Ejemplos/trunk/jasperReport

- ReporteContometroAction.java: Método

mostrarReporte

APLICACIÓN

WEB

ALTAMENTE

INTERACTIVAS

FLEX

Adobe Flex agrupa una serie de tecnologías para dar soporte

al despliegue y desarrollo de Aplicaciones de Internet Ricas,

basadas en su plataforma propietaria Flash.

El objetivo de Flex es permitir a los desarrolladores de

aplicaciones Web construir rápida y fácilmente aplicaciones

RIAs.

https://alpha:8443/svn/Ejemplos/trunk/

Manejo de logeo con envío de password encriptado

- login.mxml

ActionScripts que manejan la lógica de encriptación:

- DES.as

- TripleDES.as

OFUSCADOR

PROGUARD Es una herramienta que nos permite optimizar y ofuscar

nuestro código java una vez compilado. Ofusca renombrando

clases, métodos y campos con nombres poco legibles.

REALIZACIÓN

DE SERVICIOS

JAVA

WRAPPER

Java Service Wrapper es una herramienta que permite instalar

las aplicaciones java como servicios nativos de Windows o

Linux, permitiendo controlarlos con las herramientas propias

del SO.

https://alpha:8443/svn/Ejemplos/trunk/wrapper

Wrapper.conf: Archivo ejemplo de Configuración de

Servicio.


VV VEE ERR RSS SII I ÓÓ ÓNN N 22 2.. . 11 111 1

FECHA:05/06/2009


Página 32/32

NOTA: La inform

ación contenida en este documento no puede ser duplicada, publicada o copiada sin perm

iso escrito de HIPER S.A.

Tipo: Tipo de tecnología

Detalle: Breve descripción la cual debe comprender su propósito, aplicación.

Ejemplo: Indicar el nombre (o sección) de los archivos que lo implementan. Se tomará como ejemplo el proyecto Contómetro y cash management

Documents

Estand HIP INTG Programacion