MADES€¦ · presentación negocio persistencia Quedan fuera de esta norma los paquetes de...

Consejería de Hacienda y Administración Pública

Dirección General de Tecnologías de la Información y Comunicación

MADES

Convenio de codificación en JAVA

06/03/2018

Queda prohibido cualquier tipo de explotación y, en particular, la reproducción, distribución, comunicación pública y/o transformación,total o parcial, por cualquier medio, de este documento sin el previo consentimiento expreso y por escrito de la Consejería de Hacienda yAdministración Pública de la Junta de Extremadura.



Avda. Valhondo S/NEdificio III MilenoMódulo 2 - 3ª planta06800 - Mérida

JUNTA DE EXTREMADURA

MADES


HOJA DE CONTROL

Proyecto MADES (Marco para el Desarrollo y Mantenimiento de los S.I.)

Documento Convenio de codificación en JAVA

Nombre del Fichero MADES - Convenio de codificación en JAVA.odt

Autor

Versión/Edición 1.0 Fecha Versión 06/03/2018

Aprobado por Fecha Aprobación

REGISTRO DE CAMBIOS

Versión Causa del Cambio Responsable del Cambio Área Fecha del Cambio

CONTROL DE DISTRIBUCIÓN

Nombre y Apellidos Cargo Área Nº Copias

Página 2 de 22





MADES


ÍNDICE

1 REGLAS DE CODIFICACIÓN ................................................................................... 4

1.1 Clases e interfaces ............................................................................................................................. 4 1.2 Métodos e identificadores ............................................................................................................... 5 1.3 Comentarios ....................................................................................................................................... 5 1.4 Paquetes ............................................................................................................................................... 6 1.5 Parámetros y variables ..................................................................................................................... 8 1.6 Estructura y formato de ficheros .................................................................................................. 8

2 REGLAS DE CONSTRUCCIÓN EN JAVA ........................................................... 10

2.1 Clases e interfaces .......................................................................................................................... 10 2.2 Métodos ............................................................................................................................................. 14 2.3 Identificadores .................................................................................................................................. 17 2.4 Estructuras de control ................................................................................................................... 19 2.5 Importación de paquetes ............................................................................................................... 20 2.6 Cadena de caracteres ..................................................................................................................... 20 2.7 LOG .................................................................................................................................................... 21

3 HERRAMIENTAS ........................................................................................................ 22

3.1 Fichero de configuración de reglas de codificación ................................................................ 22

Página 3 de 22





MADES


1 REGLAS DE CODIFICACIÓN

1.1 Clases e interfaces

Nomenclatura de clases e interfaces

Usar nombres descriptivos para las clases e interfaces.

Los nombres de las clases serán descriptivos y no muy largos, usándose por logeneral sustantivos o adjetivos. La primera letra de cada palabra que forme el nombre de laclase DEBE estar en mayúsculas. PUEDE introducirse la palabra "Class" al final del nombre deuna clase para diferenciarla de las interfaces. Las clases abstractas DEBEN finalizar con lapalabra "Abstract". Esta misma normativa deberá emplearse para los nombres de lasinterfaces.

Sufijos en la Nomenclatura de Clases e Interfaces

Utilizar los sufijos indicados en función del tipo de clase implementada.

Se han definido una serie de sufijos que han de utilizarse en función del tipo de claseimplementada:

• Objeto bean de transporte de datos entre capas (típico POJO): sigue el patrón ValueObject, por lo que se DEBERÍAN definir con el sufijo VO. La única excepción es quepor convención una determinada herramienta obligue a nombrarlo con otro sufijo.Ejemplo: DatoVO.

• Objeto bean (POJO) de transporte de datos entre diversas máquinas (por ejemplo,por APIs Web Services). Todos sus elementos DEBEN implementar Serializable. Eneste caso el objeto sigue el patrón Data Access Object por lo que DEBEN nombrarsecon el sufijo DTO. Ejemplo: DatoDTO.

• Objeto de acceso a datos: DEBEN nombrarse con el sufijo DAO (Data AccessObject). Ejemplo: ProvinciaDAO.

• Como regla general, aquellas clases que implementen una funcionalidad característicao un patrón de diseño definido diferente a los anteriormente expuestos, DEBENindicarlo mediante un sufijo en la denominación del nombre de la clase. El sufijo debe

Página 4 de 22





MADES


ser lo suficientemente descriptivo para favorecer la comprensión de la funcionalidadde la clase. Por ejemplo, si creamos una clase para manejar las operaciones de unacuenta bancaria y empleamos el patrón SessionFacade, habría que denominar a laclase como AccountSessionFacade.

En función de una separación entre la interfaz y su implementación: Interfaces y clasesque implementan la interfaz NO DEBEN llevar prefijo o sufijo (no utilizaremos I comoprefijo) y las clases que implementan una interfaz DEBEN llevar el sufijo Impl.

1.2 Métodos e identificadores

Uso de Get y Set

Emplear "get" y "set" para consultar o modificar atributos respectivamente.

Se DEBEN emplear los términos "get" y "set" para identificar los métodosencargados, respectivamente, de consultar o establecer los atributos de la clase.

Se PUEDE utilizar el identificador “is” en el caso de la consulta de un atributo de tipobooleano.

1.3 Comentarios

Comentarios sobre la implementación

Incluir comentarios en el código indicando las decisiones de implementación.

Se DEBERÍA incluir comentarios en la implementación para facilitar la comprensióndel código, facilitando el mantenimiento, la mejora de las aplicaciones y la reutilización delcódigo. Estos comentarios describirán por qué se toman ciertas decisiones en laimplementación.

Javadoc

Usar Javadoc para generar la documentación de las aplicaciones.

Página 5 de 22





MADES


Se DEBE estandarizar el uso de Javadoc para generar la documentación de lasaplicaciones ya que resulta de gran utilidad para la comprensión del desarrollo.

A la hora de incluir los comentarios, es preferible el uso de la tercera persona en loscomentarios, ya que la documentación suele estar destinada a un público amplio.

Los comentarios se DEBEN ubicar siempre antes de las clases, métodos, interfaces yatributos a describir.

Todos los interfaces y métodos públicos DEBEN documentarse.

OPCIONALMENTE las clases y métodos privados pueden comentarse o no, dejandoa criterio del desarrollador esta decisión.

1.4 Paquetes

Estructura de paquetes

Estructurar el código de la aplicación en paquetes según el patrón dado.

Los paquetes de las aplicaciones JAVA desarrolladas para las distintas consejeríasDEBEN seguir el siguiente patrón:

es.juntaex.AREATEMATICA.APLICACION.[SUBSISTEMA].[CAPA].[TIPO]

Se DEBE evitar que existan clases en el paquete raíz. Esta nomenclatura permitirámejorar la comprensión de la estructura de clases de los desarrollos producidos. Habrá queconsiderar el tamaño de la aplicación para realizar una división por subsistema odirectamente dividir por capa la estructura de paquetes de la aplicación.

Quedan fuera de esta norma los paquetes de proyectos reutilizados de otras ÁreasTemáticas.

Capa en la estructura de paquetes

El patrón CAPA de la estructura de paquetes debe ser presentación, negocio o persistencia.

Dentro del patrón para la estructura de paquetes, la CAPA DEBE ser uno de lossiguientes:

Página 6 de 22





MADES


● presentación

● negocio

● persistencia

Quedan fuera de esta norma los paquetes de proyectos reutilizados de otras consejerías.

Tipo en la estructura de paquetes

El tipo indicado depende de la capa a la que está asociado.

El tipo es variable en función de la capa, así que los paquetes definidos por cada capaDEBEN ser los siguientes:

○ persistencia.dao: agrupan las interfaces de los DAO's de la capa depersistencia.

○ persistencia.dao.impl: implementación de las interfaces de acceso a datos.

○ persistencia.entidades: agrupa a las clases de entidad que dan origen a lastablas en la base de datos.

○ persistencia.interfaces: agrupa a las interfaces globales (factoría, genérico,...).

○ persistencia.util: agrupa a las clases de apoyo (criteria, etc...).

○ negocio.servicios: agrupa a las interfaces que separan la lógica de negocio.

○ negocio.servicios.impl: agrupa a las clases que implementan las interfaces delógica de negocio.

○ negocio.vo: agrupa a la clases encargadas de transporte de datos entre capas.

○ negocio.dto: agrupa a la clases de transporte de datos entre diversasmáquinas.

○ negocio.util: agrupa a las clases de apoyo (excepciones, autenticación....).

○ presentacion.util: utilidades de apoyo a la capa de presentación (validadorespersonalizados, etc...).

○ presentacion.controlador: agrupa a las interfaces que hacen de puente entreel usuario y la capa de negocio (action que produce JSF,...).

Página 7 de 22





MADES


○ presentacion.controlador.impl: agrupa a las clases que implementanlasinterfaces que hacen de puente entre el usuario y la capa de negocio

1.5 Parámetros y variables

Nomenclatura de parámetros y variables

Nomenclatura de identificadores

Los nombres de las variables y parámetros NO DEBERÁN empezar con caracterescomo "_" o "$".

1.6 Estructura y formato de ficheros

Estructura interna de los ficheros

Crear los ficheros JAVA con la estructura interna que se indica.

Los ficheros fuente JAVA se DEBEN estructurar de la siguiente forma y siguiendo elsiguiente orden:

● Comentarios de inicio

● Sentencia Package

● Sentencias Import

● Cuerpo de la clase o interfaz

Cada fichero JAVA DEBE contener una sola clase pública o interfaz. En el caso declases privadas o interfaces asociadas a una clase pública, se pueden colocar en el mismofichero que la clase pública, siendo ésta la primera clase del fichero.

Página 8 de 22





MADES


Alineación

Establecer 3 caracteres para la alineación.

La sangría DEBE ser de 3 caracteres y DEBEN ser espacios en blanco. NO SE DEBEutilizar el carácter de tabulador.

Ubicación de llaves “{ }”

Usar las llaves "{}" de la manera que se expone a continuación.

La llave de apertura de un bloque de código se DEBE ubicar siempre al final de laprimera línea, mientras que la llave de cierre DEBE ir sola en una línea, alineada con la mismacolumna que la primera línea del bloque. Se DEBE aplicar un nivel más de sangría a lassentencias que vayan entre las llaves.

Codificación ISO-8859-1

Usar la codificación ISO-8859-1 sólo cuando usar UTF-8 no sea posible

Se RECOMIENDA utilizar la codificación UTF-8 y solamente utilizar la codificaciónISO-8859-1 cuando sea estrictamente necesario por problemas de compatibilidad.

Página 9 de 22





MADES


2 REGLAS DE CONSTRUCCIÓN EN JAVA

A la hora de definir código en el proceso de construcción de un desarrollo esnecesario tener claros los siguientes objetivos:

● Realizar un código claro, eficiente y estructurado que facilite un posiblemantenimiento del mismo.

● Producir un código con el menor número de errores posibles.

● Realizar un código en base a un estándar de construcción que facilite lareutilización de componentes en la construcción.

● Documentar con eficiencia el código para facilitar la compresión del mismo.

● Tener en cuenta las cuestiones de rendimiento a la hora de programar,intentando encontrar soluciones que minimicen el consumo de recursos delsistema.

Para asegurar que se cumplen estos objetivos definimos este el conjunto dedirectrices que se describen a continuación.

2.1 Clases e interfaces

Creación de clases innecesarias

No crear clases que no se vayan a usar posteriormente.

Sólo se DEBEN crear las clases que sean realmente necesarias para nuestrodesarrollo.

Cohesión de las clases

Conseguir una alta cohesión.

La cohesión es la medida que indica si una clase tiene una función bien definidadentro del sistema. El objetivo es enfocar de la forma más precisa posible el propósito de laclase, cada clase DEBE poseer un propósito claro y simple. NO se DEBE mezclar varios

Página 10 de 22





MADES


propósitos funcionales dentro de una misma clase ya que puede provocar confusión, erroresde interpretación y dificultar la detección de errores.

Acoplamiento entre clases

Conseguir un bajo acoplamiento entre clases.

Deberemos intentar que nuestras clases tengan un acoplamiento bajo. Elacoplamiento entre clases es una medida de la interconexión o dependencia entre clases.Cuantas menos cosas conozca una clase de otra menor será su acoplamiento. Una clasedebe conocer los métodos que ofrece otra, pero, por norma general, no los detalles deimplementación o sus atributos.

Clases finales

No declarar las clases como finales, excepto por motivos de seguridad.

Al declarar una clase como final impedimos que se puedan crear subclases quehereden de ésta. Por este motivo, NO SE RECOMIENDA crear clases finales. Tan sólodeben crearse clases finales por motivos de seguridad, para impedir que se puedan crearsubclases que implementen alguna funcionalidad que pueda perjudicar a la aplicación ocuando todos los métodos constructores de la clase sean privados.

Atributos de clases finales

Asegurar que los atributos de las clases finales no estén definidos como protected.

Los atributos de las clases finales DEBEN declararse como públicos o privados, perono deben declararse como protegidos. Esto se debe a que las clases finales no se puedenderivar, por lo que el uso del modificador de acceso protegido puede crear confusiones.

Clases internas

Usar clases internas cuando el grado de acoplamiento sea elevado.

Página 11 de 22





MADES


Se RECOMIENDA utilizar clases internas cuando el grado de acoplamiento entreciertas clases sea muy elevado, pero sin descuidar el tamaño de dichas clases para noaumentar la complejidad. Las clases internas no deben sobrepasar las 60 líneas de código.

Inicialización de clases

Inicializar las clases y superclases en un estado conocido.

Las clases y superclases DEBEN inicializarse a un estado estable y conocido paraevitar conflictos iniciales y que puedan aparecer ciclos dentro de los inicializadores estáticosque ocasionen errores graves en la aplicación.

Herencia

Sólo se deben crear clases que hereden de otras cuando se vaya a ampliar la funcionalidadde la clase padre en la clase hija.

La herencia consiste en la creación de clases que extienden de otras. Esto es, unaclase que añade características propias al contenido de otra clase de la que hereda. Por lotanto, sólo se DEBE crear clases que hereden de otras cuando se vaya a ampliar lafuncionalidad de la clase padre en la clase hija.

Interfaces

Usar las interfaces para establecer 'protocolos' entre las clases.

Se DEBE utilizar las interfaces para establecer protocolos entre las clases, ya queéstas permiten establecer la forma de una clase (nombres de métodos, listas de argumentosy tipos de retorno, pero no bloques de código). En ellas se especifica qué se debe hacerpero no su implementación. Serán las clases que implementen estas interfaces las quedescriban la lógica del comportamiento de los métodos.

Tipos de interfaces

Crear diferentes tipos de interfaces para diferentes tipos de usuarios.

Página 12 de 22





MADES


Se RECOMIENDA la creación de diferentes tipos de interfaces según el tipo deusuario para proporcionar un sistema más comprensible desde las diversas perspectivas quepuede haber en el mismo. De este modo conseguimos reducir el impacto pormantenimiento.

Interfaces frente clases abstractas

Usar las interfaces en lugar de clases abstractas.

Se RECOMIENDA promover el uso de interfaces, en lugar de clases abstractas, paraaquellos casos en los que se tenga pensado dar distintas implementaciones a un mismométodo. Esto se debe a que las interfaces son más flexibles que las clases abstractas,permitiendo herencia múltiple en JAVA. Se RECOMIENDA utilizar clases abstractas sólocuando se implemente cierta funcionalidad que deba ser compartida por todas las subclases.

Interfaces redundantes

Evitar crear interfaces redundantes.

Existen clases que declaran e implementan una interfaz que también es implementadapor una superclase. Esto es redundante porque una vez que una superclase implementa unainterfaz, todas las subclases de forma predeterminada también implementan esta interfaz.

Clases del API JAVA

Usar o extender en la medida de lo posible las clases del API JAVA.

Se RECOMIENDA usar o extender en la medida de lo posible las clases del APIJAVA, ya que suelen ofrecer un rendimiento nativo de máquina que no se puede igualarutilizando una implementación JAVA propia. Por ejemplo, el métodojava.lang.System.arraycopy() es mucho más rápido a la hora de copiar un array de cualquiertamaño que si implementamos nuestro propio bucle para copiar cada uno de sus elementos.

Interfaz Serializable

Definir el atributo serialVersionUID y crear un constructor vacío, si la clase tiene unasuperclase.

Página 13 de 22





MADES


Para optimizar el uso de la interfaz Serializable se DEBE definir el atributoserialVersionUID y crear un constructor vacío, si la clase tiene una superclase. Además, seDEBEN declarar como private los métodos para la "serialización" o "deserialización", en casode definirlos.

2.2 Métodos

Creación de métodos innecesarios

No crear métodos que no se vayan a usar posteriormente.

Sólo debemos crear los métodos que sean realmente necesarios para nuestrodesarrollo. No DEBEN aparecer métodos que no se utilicen.

Funcionalidad de los métodos

Minimizar las funcionalidades asignadas a cada método.

Cada método debe poseer una funcionalidad clara y simple, por lo que se DEBEseparar los métodos que cambian de estado de aquellos que los consultan. De esta manera,simplificamos el control de concurrencia y extensiones por herencia.

Métodos get/set

Evitar el mal uso de los métodos get/set.

Crear los métodos de acceso y consulta de datos necesarios, teniendo en cuenta quemuchos de los atributos tienen dependencias entre ellos para mostrar un valor conjunto y lagestión individual de los mismos puede provocar errores.

Métodos constructores

Dotar de la mínima funcionalidad a los métodos constructores.

Página 14 de 22





MADES


Los métodos constructores serán lo más simples posible, evitando llamadas amétodos reemplazables (overridable) y métodos que no sean finales, ya que éstos podríanser redefinidos, causando errores en la construcción.

Constructores por defecto

Definir un constructor por defecto.

Debemos crear un constructor por defecto, sin parámetros, cuando existanconstructores con argumentos en la clase. De esta forma facilitamos la carga dinámica declases de tipo desconocido en tiempo de compilación, mejorando el rendimiento de laaplicación.

Método finalize()

Declarar el método finalize como protected.

Se DEBE declarar el método finalize como protected, en caso de sobreescribirlo,asegurando que se realizan acciones previas a la invocación del método super.finalize().Además, habrá que evitar que este método pueda ser llamado por el recolector de basura,cuando no haya más referencias al objeto, y que contenga parámetros, ya que podría ocurrirque la máquina virtual no lo invocara.

Existencia del método finalize()

Asegurar la existencia de un método finalize para las clases que crean recursos.

El método finalize debe eliminar los recursos (objetos, referencias, etc.) creados porel constructor, normalmente en el orden inverso al que fueron creados. Si una clase creaalgún tipo de recurso DEBE implementar el método finalize().

Método main()

Escribir un método main para cada clase relevante.

Se recomienda crear un método main para facilitar los test y las pruebas de las clases.

Página 15 de 22





MADES


Método clone()

Sobreescribir el método clone cuando un objeto pueda ser copiado.

Se RECOMIENDA sobrescribir el método clone() cuando un objeto pueda sercopiado, ya que el método de la clase Object realiza una copia que puede no tener el nivelde profundidad buscado. A la hora de sobrescribir este método tenemos que tener encuenta que la clase DEBE implementar la interfaz Cloneable y que DEBE lanzar la excepciónCloneNotSupportedException para prevenir que la operación de clonación se ejecute si nose ha otorgado el permiso para ello.

Métodos hashCode() y equals()

Asegurar que si una clase sobreesscribe el método hashCode() también sobreescribe elmétodo equals().

Estos métodos son especialmente importantes si vamos a guardar nuestros objetosen cualquier tipo de colección: listas, mapas, etc. y más aún si los objetos que vamos aguardar en la colección son serializables.

Comunicación entre hilos

Usar los métodos wait(), notify() y notifyAll().

Para realizar la comunicación entre hilos se DEBE usar los métodos wait(), notify() ynotifyAll().

Métodos finales

Usar métodos finales cuando se quiera proteger de sobreescritura.

Debemos crear métodos finales cuando queramos evitar que éstos sean sobrescritospor las subclases. Para ello, utilizaremos la palabra clave "final" en la declaración del método.

Página 16 de 22





MADES


2.3 Identificadores

Declaración de atributos públicos

Nunca declarar como público un atributo de una clase.

Se DEBE evitar el uso de atributos públicos, ya que no debemos dar el control de laestructura interna de la clase a desarrolladores externos. En su lugar, los atributos sedeclararán privados (private) excepto los que sean accesibles por herencia que deben serdeclarados como protegidos (protected).

Declaración de atributos protegidos

Favorecer el uso de atributos protegidos en lugar de privados.

Se RECOMIENDA que los atributos se definan como protegidos salvo que existanrazones muy importantes como para negar el uso de un atributo en las subclases. Estoimplica un mayor control sobre estos atributos ya que éstos pueden ser accedidos desdeclases externas.

Atributos estáticos

Minimizar el uso de atributos estáticos.

Se RECOMIENDA minimizar el uso de atributos estáticos ya que, al tener uncomportamiento similar a las variables globales, provocan que los métodos dependan másdel contexto y sean menos reutilizables.

Inicialización de atributos estáticos

Asegurar que los atributos estáticos tengan valores válidos.

Hay que asegurar que las partes estáticas se inicializan correctamente ya quepodemos obtener errores al poder invocarse sin necesidad de instanciar la clase.

Página 17 de 22





MADES


Modificador "final" en variables

Usar final para variables que no cambien de valor.

Se DEBE utilizar el modificador "final" en aquellas variables que no se van a modificarpara evitar que se realicen controles sobre ellas. Si añadimos el modificador "static" a estasvariables las convertimos en constantes.

Variables nuevas

Usar variables nuevas y controlar el número de las mismas.

Se RECOMIENDA crear las variables que sean necesarias, controlando que no secreen más de las debidas, en lugar de reutilizar las variables definidas que no se volverán ausar dentro del código.

Tipo de las variables para uso monetario

Usar la clase java.math.BigDecimal para aquellas variables de uso monetario.

Se RECOMIENDA utilizar la clase java.math.BigDecimal, proporcionada por JAVA, enaquellas variables que tengan un uso monetario ya que permite realizar cálculos con puntoflotante con la precisión requerida. NO SE RECOMIENDA el uso de los tipos float o doubleya que éstos introducen pequeños márgenes de imprecisión que pueden producir errores enlos cálculos.

2.4 Estructuras de control

Simplificación de las condiciones

Simplificar la complejidad de las condiciones expresadas mediante el uso de operadoreslógicos.

Se RECOMIENDA no anidar más de tres operadores lógicos a la hora de crear unacondición dentro del código, ya que la concatenación de más operadores lógicos puede

Página 18 de 22





MADES


provocar una disminución significativa en el rendimiento y en el mantenimiento de laaplicación.

Complejidad del código

Comprobar la complejidad ciclomática del código contra un límite especificado.

Se RECOMIENDA comprobar la complejidad ciclomática del código contra un límiteespecificado, midiendo el número de instrucciones del tipo if, while, do, for, catch, switch,case y los operadores && y || en el cuerpo de un constructor o el método inicializador de laclase.

Instrucciones de tipo If

No podrán contener un bloque de código vacío y deberán utilizarse para sentencias lógicascuyo valor cambie.

Las instrucciones de tipo If NO DEBEN contener un bloque de código vacío yDEBERÁN utilizarse para sentencias lógicas cuyo valor cambie. NO DEBEN asignar un valorlógico a una variable dentro del bloque. Además, las instrucciones If que sean colapsablesentre sí DEBEN sustituirse por un operador lógico que maneje la condición.

Instrucciones de tipo Switch

Siempre tendrán un caso por defecto.

Las instrucciones de tipo Switch siempre DEBEN tener un caso por defecto y noDEBEN tener bloques de código vacíos.

Expresiones invariables en bucles

Eliminar las expresiones invariables de los bucles.

Se DEBE extraer del interior de los bucles todas las expresiones cuya ejecuciónproduzca siempre el mismo resultado.

Página 19 de 22





MADES


2.5 Importación de paquetes

Evitar la importación de paquetes usando '*'.

NO se DEBEN importar paquetes usando '*', ya que puede dificultar el seguimientode las dependencias y provocar duplicidades de paquetes importados. Además, se DEBENimportar sólo aquellos paquetes que se vayan a usar, evitando realizar importaciones depaquetes 'sun.*' ya que éstos no son portables y tienden a cambiar.

2.6 Cadena de caracteres

Usar la clase StringBuffer cuando se trabaje con cadenas de caracteres.

Se RECOMIENDA usar la clase StringBuffer cuando se vayan a manipular, de maneraintensiva (reemplazando caracteres, añadiendo o suprimiendo, etc.), cadenas de caracteres,ya que usar la clase String resulta poco conveniente.

2.7 LOG

Utilización del System.out

Emplear la función System.out o similares para enviar mensajes a consola.

NO se DEBE hacer invocación directa a la consola, por lo que se descartanmecanismos de log como: System.out.println(“Consultandoel API”);

Este tipo de llamadas sólo serán aceptadas en pruebas unitarias de JUnit.

Niveles de prioridad de log

Utilizar el nivel de log adecuado para cada entorno.

Página 20 de 22





MADES


En caso de realizar un seguimiento a un nivel muy bajo, la ejecución de lasaplicaciones se puede ralentizar, y el log se convertiría en ilegible. Por tanto en tiempo depruebas o desarrollo se PUEDE utilizar el nivel más bajo de log, DEBUG, pero una vez laaplicación se encuentre en un entorno de producción se DEBE utilizar solo el nivel ERRORo WARN.

Página 21 de 22





MADES


3 HERRAMIENTAS

3.1 Fichero de configuración de reglas de codificación

Como ayuda para los desarrolladores se facilita un fichero de configuración paraEclipse con las reglas de formateo de código que se describen en este documento. El ficherose encuentra en Herramientas→ JAVA→ “formatterEclipseDGTIC.xml”. Para poder utilizarlodebemos importarlo en Eclipse dentro de la opción Window→ Preferences→ Java→ CodeStyle → Formatter.

Página 22 de 22

MADES€¦ · presentación negocio persistencia Quedan fuera de esta norma los paquetes de...

Documents

Transcript of MADES€¦ · presentación negocio persistencia Quedan fuera de esta norma los paquetes de...