Estandares de Programacion - v1-6

Estndares de Programacin CNTI
Estndares de Programacin Elaborado por: Danela Gutirrez, Ana Fernandes Revisado por: Yasibit Reao
Versin: 1.6 Aprobado por: Richard Perna
Av. Andrs Bello, sector Guaicaipuro, Torre MPPTI, piso 17, Municipio Libertador, Caracas. Telf. +58 (212)- 507.45.90 - Sitio Web: www.cnti.gob.ve 1 de 26
Historial de Revisiones
Versin 1.0 1.1 Fecha 29/09/11 19/10/11 Autor Danela Gutirrez Danela Gutirrez Descripcin - Revisin del documento - Incorporacin de las observaciones suministradas por Yasibit Reao en su revisin - Revisin del documento e informacin investigada por Ana Fernandes - Integracin de informacin del documento con la suministrada por Ana Fernandes - Revisin del documento e incorporacin de informacin discutida en reunin - Incorporacin de recomendaciones - Arreglo de detalles del documento
1.2 1.3 1.4 1.5 1.6
20/10/11 24/10/11 25/10/11 28/10/11 25/11/11
Danela Gutirrez Ana Fernandes Danela Gutirrez Danela Gutirrez Ana Fernandes Danela Gutirrez Ana Fernandes Danela Gutirrez
ndice de contenido
1. Introduccin............................................................................................................................. 4 2. Estndares y Convenciones de Nombre..................................................................................5 2.1 Convencin de Nombres para Elementos UI.......................................................................9 3. Indentacin.............................................................................................................................. 10 4. Buenas Prcticas de Programacin.........................................................................................11 4.1 Declaraciones...................................................................................................................... 11 4.2 Sentencias o Instrucciones..................................................................................................12 4.3 Hbitos de Programacin.....................................................................................................12 4.4 Interaccin con Base de Datos............................................................................................16 4.5 Manejo de Mensajes............................................................................................................ 17 5. Arquitectura ............................................................................................................................ 18 6. Programacin Web.................................................................................................................. 18 7. Comentarios............................................................................................................................ 20 8. Manejo de Excepciones........................................................................................................... 21 9. Parametrizacin y Configuracin de una aplicacin................................................................21 10. Sobre la organizacin de una aplicacin a nivel de Sistema de Archivos..............................22 11. Sobre las Estructuras de Datos (Persistencia).......................................................................24 12. Sobre la Seguridad................................................................................................................ 26 13. Recomendaciones.................................................................................................................. 27 14. Referencias........................................................................................................................... 27
Estndares de Programacin CNTI

1. Introduccin
Este documento se ha realizado con la finalidad de definir estndares de programacin y buenas prcticas para ser tomadas como referencia para el desarrollo de aplicaciones. Existen diversos criterios para definir una buena codificacin. Entre los criterios ms importantes se encuentran: Confiabilidad, Mantenibilidad y Eficiencia. La mayora de los desarrolladores se esfuerzan por la realizacin de un cdigo eficiente para proporcionar un mayor rendimiento, comprometiendo la confiabilidad y facilidad de mantenimiento del mismo. Si el cdigo no es confiable y mantenible, se invierte mucho tiempo en la deteccin de los problemas en el momento de resolver alguna falla, tratando de entender el cdigo, entre otras cosas. Para evitar estos inconvenientes, es aconsejable seguir estndares y buenas prcticas de programacin. Las mismas sern descritas a lo largo del documento.
2. Estndares y Convenciones de Nombre

Las convenciones de nombres hacen los programas ms entendibles, es decir, ms fciles de leer. Tambin pueden dar informacin sobre la funcin de un identificador, por ejemplo, si es una constante, un mtodo, una variable, entre otros. Es importante que se use la convencin de manera consistente, lo contrario hace que el cdigo sea difcil de seguir. Por ejemplo, el uso de variables a, abc, x, deben evitarse a toda costa. Se recomienda no usar abreviaturas, a menos que sea una abreviatura clara y ampliamente usada en el rea de aplicacin de software como CPU, URL, entre otras. Hay casos que contradicen esta recomendacin, como el uso de contadores o ndices para iterar
Estndares de Programacin Elaborado por: Danela Gutirrez, Ana Fernandes Revisado por: Yasibit Reao Versin: 1.6 Aprobado por: Richard Perna
sobre una estructura de datos (i, j, k), ya que histricamente se han usado as. Los nombres pueden estar en ingls o espaol. Se debe evitar es usar distintos idiomas a la vez, es decir, nombres en ingls y espaol en la misma clase. A continuacin se presenta un cuadro con los estndares de nombres: Tipo de Identificador Reglas para nombrar Los nombres de los archivos de cdigo fuente deben basarse en palabras o combinaciones de palabras que expresen de alguna forma el propsito intrnseco al archivo. Si el archivo contiene una clase, debe llevar el nombre de la clase. La primera letra de cada palabra debe ir en mayscula, y el resto en minscula. Se escribe siempre en minscula y por lo general se usa el nombre del dominio de internet de la organizacin. Los subsecuentes componentes del nombre varan de acuerdo a la organizacin de la aplicacin Los nombres de las clases deben ser sustantivos (una clase es una plantilla, a partir de la cual se instancian objetos. Los Ejemplos
Programas
Presidencia.html PresupuestoAnual.java RegistrarUsuario.php
Paquetes (cuando aplique)
Para el caso del CNTI podra ser: ve.cnti.genportal.plantillas
Clases
class Usuario class UsuarioAdministrador

Versin: 1.6
Aprobado por: Richard Perna
nombres de los objetos en la vida real son sustantivos). Cuando los nombres son compuestos, la primera letra de cada palabra que los forman deben ir en mayscula. Los nombres de las clases deben ser simples y descriptivos. Se recomienda usar palabras completas, evitar acrnimos y abreviaturas (a no ser que la abreviatura sea mucho ms conocida que el nombre completo, ejemplo URL o HTML) interfaz Almacn Interfaces (Cuando aplique) Siguen la misma regla que las clases Los mtodos o funciones deben ser verbos. El nombre de los mtodos y funciones debe ser en minscula. Cuando los nombres son compuestos, la primera letra de la primera palabra debe ser en minscula y la primera letra de las siguientes palabras que lo forman en mayscula. Los mtodos y funciones deben ser cortos y fciles de entender., y deben hacer una sola cosa. Todas las variables empezarn interfaz VistaGenerica
ejecutar() agregarUsuario() function getPassword()
Mtodos / Funciones
Variables
Estndares de Programacin Elaborado por: Danela Gutirrez, Ana Fernandes
int tmp
Versin: 1.6
Revisado por: Yasibit Reao
Aprobado por: Richard Perna
con minscula. Las palabras internas que lo forman (si son compuestas) empiezan con su primera letra en mayscula. Nunca utilizar el guin bajo para separarlas. Los nombres de las variables deben ser cortos y con significado. La eleccin del nombre de una variable debe ser un mnemnico, designado para indicar a un observador casual su funcin. Evitar el uso de abreviaturas sin significado alguno, como a, b, dd, entre otros. Esto es recomendado solamente cuando la abreviatura es muy conocida como tmp para temporal o i,j,k para ndices. Es preferible un nombre de variable extenso pero con significado claro.
float impuesto double totalSinIVA $montoConIVa
Constantes
Deben ir totalmente en mayscula separando las palabras con un underscore (_)
static final int ANCHURA_MINIMA = 4; static final int IVA = 0,09; $IVA = 0,9; Debe ir totalmente en minscula. Las palabras internas que lo forman (si son compuestas) empiezan con su primera letra en mayscula.
Propiedades
Visible Border
Archivos
Se debe escribir cada palabra con la primera letra en maysculas y el resto en minsculas. Los archivos asociados asociados a clases deben llevar el nombre de la clase.
Usuario.class.php Usuario.db.php
2.1 Convencin de Nombres para Elementos UI Para el manejo de elementos UI, tambin se debe considerar estandarizar los Nombres. Existen elementos que son manejados por un lenguaje en particular, sin embargo, hay algunos que son comunes en la mayora de los lenguajes. El nombre de estos elementos debe tener un prefijo que describa el elemento en minscula, seguido de un nombre significativo que defina el (los) dato(s) que representa. Ej.: txtNombre (Para un text box que guarde el nombre de un usuario). A continuacin se presenta una tabla con los elementos UI ms utilizados y sus prefijos: Elemento UI Label TextBox DataGrid Button ImageButton ListBox lbl txt dtg btn imb lst Prefijo
DataList Checkbox RadioButton Image Panel Table
dtl chk rdo img pnl tbl
3. Indentacin
Se debe utilizar como unidad de indentacin un tabulador (el cual debe ser de 8 espacios). Evitar las lneas de 80 caracteres ya que no son manejados por algunos editores. Cuando una expresin no cabe en una lnea, se debe hacer el salto de lnea de acuerdo a los siguientes principios: (a) Romper despus de una coma. (b) Romper antes de un operador. (c) Utilizar rupturas de alto nivel (ms a la derecha que el padre) y no las de bajo nivel (ms a la izquierda que el padre). (d) Alinear la nueva lnea con el comienzo de la expresin al mismo nivel de la lnea anterior.
(e) Si las reglas anteriores llevan a un cdigo confuso o a cdigo que se aglomera al margen derecho, identar solo un tabulador (8 espacios) en su lugar. Hay que procurar no mezclar inadecuadamente tabulaciones con espacios. Por lo que se recomienda usar solo tabulador. Las sangras de tabulador (8 espacios) hacen que el cdigo sea ms fcil de leer y tiene un beneficio aadido de sealar el cdigo anidado.
4. Buenas Prcticas de Programacin

4.1 Declaraciones (a) Se debe colocar una declaracin por lnea. (b) Inicializar las variables locales donde sean declaradas. Algunos errores de compilacin se producen cuando una variable es declarada sin ser inicializada. (c) Colocar la declaracin/inicializacin de las variables solo al principio de un bloque. No esperar a usarla por primera vez para declararla ya que esto puede dar pie a confusiones. La nica excepcin a esta regla son los ndices de los bucles for. (d) Evitar las declaraciones locales que oculten declaraciones de niveles superiores. Por ejemplo no declarar la misma variable en un bloque interno. Ejemplo: int cuenta; ...... miMetodo(){ if (condicin) { int cuenta = 0; } }
(e) En la programacin orientada a objetos, no hacer los atributos pblicos ni protegidos, estos deben ser siempre privados. Para acceder al valor de los mismos, se deben crear mtodos pblicos. 4.2 Sentencias o Instrucciones (a) Debe haber solo una sentencia por lnea y debe ser lo ms simple posible. Si una sentencia es muy grande, debe ser dividida aunque ocupe varias lneas. se pretende mantener la claridad ante todo. (b) Siempre se deben usar las llaves de apertura y cierre en las sentencias de cdigo que lo amerite, as contenga solo una instruccin. Ejemplo: if (condicin) { sentencias; } else{ sentencias; } Lo mismo aplica para sentencias For, While y Switch. (c) En una sentencia Swtich, todos los Case deben incluir la sentencia break; cuando ocurran excepciones de esta regla, se debe indicar un comentario donde la sentencia break se encontrara normalmente. (d) Cada sentencia Switch debe incluir un caso por defecto. El break en el caso por defecto es redundante siempre y cuando la sentencia est de ltima, de no ser as, es necesario colocarlo ya que prevee que evita que se ejecute el caso que le sucede. (e) Aunque el valor de la variable de control puede cambiarse en el cuerpo del ciclo for, se debe evitar hacerlo, pues esta prctica puede generar sutiles errores de lgica.
4.3 Hbitos de Programacin (a) Se recomienda dividir el sistema en varias clases, para que sea ms sencillo su mantenimiento y siempre pensando en la expansin y crecimiento del mismo. (b) Evitar el uso de objetos para acceder a una variable o mtodo de tipo esttico. Ejemplo: UnaClase.metodoDeClase(); // OK unObjeto.metodoDeClase(); // EVITAR (c) Nunca usar nmeros directamente sobre operaciones, en su lugar declarar estos valores como constantes. Ejemplo: subtotal = precio * IVA; // OK subtotal = precio * 0,9; // EVITAR (d) Evitar asignar el mismo valor a varias variables en la misma sentencia, ya que esto dificulta su lectura. Ejemplo: charInicial = charFinal = 'a'; // EVITAR (e) No usar asignaciones embebidas. Ejemplo: d = ( a = b + c ) + r; // EVITAR (f) Usar parntesis en expresiones que implican distintos operadores para evitar problemas con errores de precedencia de los mismos, inclusive si parece claro el orden de precedencia de los operadores. Ejemplo:
if ( ( a == b ) && ( c==d ) ) // OK if ( a == b && c==d ) // EVITAR
(f) Es recomendable utilizar dos lneas en blanco entre declaraciones de clases. adems de una lnea en blanco entre: mtodos, declaraciones de variables y la primera sentencia del mtodo, antes de un comentario y entre secciones lgicas de cdigo cuando esto mejore su legibilidad y comprensin. (g) Todas las operaciones aritmticas deben ir con espacios en blanco separando operandos de operadores. Ejemplo: a = ( b + c ) / ( c * d ); // OK (h) Se debe dejar un espacio en blanco despus de cada coma al declarar los parmetros de un mtodo. (i) Hay que mantener la coherencia y consistencia en el uso de los nombres de las clases, variables y mtodos, entre otros. Evitar el uso de nombres cortos y confusos. (j) Evitar escribir mtodos muy largos. Un mtodo regularmente tiene de 1 a 25 lneas de cdigo. Si un mtodo tiene ms de 25 lneas de cdigo, se debe considerar separarlo en varios mtodos. (k) Un mtodo debe hacer solo un trabajo. No combinar ms de un trabajo en un mtodo simple, inclusive si estos trabajos son muy pequeos. (l) Siempre hay que estar atento con los valores inesperados en las condiciones. Por ejemplo, si se est usando un parmetro que puede tener solo 2 valores, no suponer que si en uno no coincide, es automticamente el otro. Ejemplo: if (tipoPersona == 'V') { sentencias de Vendedor; }
else if (tipoPersona == 'C'){ // OK sentencias de Cliente; } (m)Las Sentencias de control deben contar con un espacio entre la palabra reservada y el parntesis. La llave siempre debe estar en la misma linea donde se esta realizando la evaluacin. (n) En la estructura ilf/else, se debe colocar en el principio las condiciones con mayor probabilidad de que sean true. Esto permite que dicha estructura se ejecute con mayor rapidez y salga antes que en los casos que suceden con menos frecuencia. (o) En las expresiones que utilizan el operador &&, si las condiciones individuales son independientes entre ellas, se debe colocar a la izquierda la condicin que ms probablemente sea false (p) En las expresiones que utilizan el operador ||, se debe colocar a la izquierda la condicin que ms probablemente sea true. Con esto es posible reducir el tiempo de ejecucin del programa. (q) Los Strings se deben convertir a mayscula o a minscula antes de realizar una comparacin entre ellos, exceptuando aquellos casos donde es preciso realizar comparaciones entre mayscula y minscula. Esto garantizar que ambas cadenas estn a la par en el momento de realizar la comparacin. Es recomendable que las comparaciones se realicen directam,ente en la sentencia SQL a ser ejecutada en la base dedatos haciendo uso de las propias funciones SQL. (r) En caso de que sea requerido estar modificando una cadena repetidamente debe utilizarse el objeto StringBuffer en vez del objeto String. (s) En la medida de lo posible, evitar el uso de variables globales. Declarar variables locales cuando sea necesario, y pasarla como parmetro a otros mtodos para evitar compartir variables. Esto permite hacerle un mejor seguimiento al valor de las variables. (t) No programar las acciones que deben ejecutar un evento click en otros mtodos. Si estas acciones son requeridas nuevamente, se debe invocar el mtodo manejador del
evento click. (u) Evitar trabajar con rutas (direcciones) constantes. Es recomendable trabajar siempre con rutas relativas. (v) Si son requeridos archivos de configuracin para que la aplicacin se ejecute, esta debe verificar la existencia de los mismos, en caso de que dichos archivos no se encuentren, la aplicacin debe ser capaz de crear unos por defecto. (w) No colocar ms de una clase en un archivo simple. (x) No trabajar con clases muy largas para hacer mas digeribles el cdigo. (y) Evitar pasar demasiados parmetros a un mtodo. Si se tienen que pasar ms de 5 parmetros, estudiar la posibilidad si estos se pueden redefinir como una estructura o una clase. (z) Se debe trabajar con clases que permitan el registro de errores, advertencias y movimientos realizados por el usuario, de manera que se generen reportes que sean visualizados por el administrador del sistema, ya sea por la misma aplicacin o por correo electrnico. (aa)Utilizar las funciones y clases de las bibliotecas estndar, en lugar de escribir versiones propias de ellas. (bb)Se debe evitar poner dentro de los ciclos expresiones cuyos valores no cambien. Pero si esto se hace, muchos de los compiladores refinados optimizadores actuales colocarn automticamente tales expresiones fuera de los ciclos, cuando se genere el cdigo de lenguaje de mquina. (cc)Se debe cerrar explcitamente cada archivo tan pronto como se deje de utilizar. Esto puede reducir el uso de recursos de un programa que continuar ejecutndose despus de que ya no necesite un archivo particular. Esta prctica tambin mejora la claridad del programa. 4.4 Interaccin con Base de Datos (a) Todas las sentencias propias del lenguaje SQL, deben se escritas en mayscula. Ejemplo: SELECT, WHERE, INSERT, UPDATE, entre otros. (b) Si se abren conexiones a base de datos, las mismas deben ser cerradas antes de
finalizar el ltimo bloque de instruccin. Esto garantizar que si ocurre una excepcin en la apertura de la conexin, esta sea cerrada satisfactoriamente al finalizar el bloque. (c) Luego de crear las consultas, se debe probar directamente sobre el manejador de base de datos para algn caso especfico y as realizar los ajustes necesarios al pasar al cdigo del programa. (d) Den la sentencia SELECT deben consultarse solo los campos que sean requeridos en lugar de todos (*) ya que se gasta menos memoria y facilita la lectura de la sentencia. (e) Al trabajar con fechas, es mucho ms rpido y fcil formatear la fecha completa en la consulta SQL trabajndola con el lenguaje de programacin que est utilizando. Utilizar la funcin date_format() de MySQL o las similares en el gestor de base de datos que est utilizando. (f) Se recomienda hacer uso de los JOIN, ya sea INNER, LEFT o RIGHT en lugar de realizar n-consultas que den el mismo resultado, ya que la ejecucin es ms lenta. 4.5 Manejo de Mensajes (a) El manejo de mensajes tanto de xito como de error, deben ser implementados a travs de configuracin (XML, tabla en la base de datos). Si la tecnologa lo permite, los mensajes deberan ser cargados desde la configuracin en alguna estructura de datos persistente en memoria principal mientras la aplicacin est funcionando u operando. (b) Los mensajes de error deben ayudar a los usuarios a resolver los problemas que se estn presentando en la aplicacin. No se deben mostrar mensajes que digan: Error en la aplicacin o Se ha producido un Error. En lugar de esto, se deben dar mensajes concretos tal como: No se ha podido actualizar la base de datos. Asegrese de que el nombre de usuario y la contrasea sean correctos. (c) Cuando se muestran mensajes de error, adems de indicar lo que est mal, debe decirle al usuario cmo resolver el problema presentado. En vez de mostrar un mensaje de este tipo: No se ha podido actualizar la base de datos, se debe mostrar uno que le de indicaciones al usuario: No se ha podido actualizar la base de datos. Asegrese de que el nombre de usuario y la contrasea sean correctos.
(d) Si al cargar una aplicacin, se encuentra un valor incorrecto en alguno de los archivos de configuracin, se debe mostrar un mensaje de error que indique a los usuarios cules son los valores correctos. (e) En la medida de lo posible, los mensajes deben ser cortos y amigables al usuario para su fcil comprensin. Para el registro real de errores en el log, se debe aportar la mayor informacin posible del error que se est presentando. Esto ayudar mucho en el diagnstico de problemas. (f) Sele debe indicar al usuario todas las entradas de teclado a travs de mensajes. Dichos mensajes deben especificar la forma de la entrada y los valores especiales que pueda tener.
5. Arquitectura
(a) Siempre usar arquitectura de n-capas. (b) Nunca acceder desde las interfaces de usuario directamente a la base de datos. Siempre debe haber una capa de clases de datos que se encarga de esta labor. Esto es de gran ayuda en el caso de migrar de una base de datos a otra. (c) En la capa de datos se debe hacen capturar todas las excepciones correspondientes a la base de datos. Los datos registrados deben incluir el nombre de los comandos en ejecucin, nombre de los procedimientos almacenados, parmetros, cadena de conexin utilizada, entre otros. Esto con el fin de que, en el caso que sea necesario, otra capa de la aplicacin sea capaz de tomar las medidas apropiadas.
6. Programacin Web
(a) Se debe evitar el uso de javaScript dentro de los archivos HTML, es preferible separarlos en un archivo (de extensin .js). (b) Se recomienda el uso de hojas de estilo (css), se debe evitar a toda costa colocar el estilo de las pginas dentro de las etiquetas HTML. Esto ayudar a realizar cambios de apariencia en las interfaces de usuario de manera rpida. (c) Se deben realizar las validaciones tanto del lado del cliente (JavaScript) como del lado
del servidor. No se deben confiar las validaciones de los formularios nicamente a JavaScript, ya que el usuario puede tener deshabilitada esta opcin. (d) No utilizar variables sesin dentro del cdigo HTML. Estas deben ser utilizadas dentro de las clases y se deben colocar mtodos que puedan acceder a los valores de las mismas. (e) No almacenar grandes objetos en variables sesin. Esto puede consumir una gran cantidad de memoria del servidor en funcin del nmero de usuarios. (f) Se debe validar que el cdigo primero funcione correctamente en todos los navegadores y y luego se adapte el desarrollo para que funcione Internet Explorer: es ms fcil hacer la pgina compatible primero con todos los navegadores y posteriormente con Internet Explorer. Adems, segn recientes estadsticas globales, estos ltimos dos aos IE ha bajado su participacin global de un 75% a un 50%. (g) Hacer uso del estndar ms actual. (HTML 4.01). (h) Evitar, en la medida de lo posible, comentar el cdigo HTML, ya que esto ocupa espacio en la transferencia y al usuario final le podr parecer lenta la carga. (i) Todo input debe tener el atributo maxlength. Esto evita en cierta manera la inclusin de cdigo malicioso. (j) En JavaScript, no utilizar el evento onKeyPress para validar el ingreso de caracteres ya que si no se suelta la tecla y se presiona enter o se pulsa en Aceptar, la validacin nunca ocurre. Se recomienda hacer la validacin una vez que el usuario ha llenado todo el formulario y pulsa en Aceptar. (k) Se debe ser cuidadoso desarrollando en JavaScript, ya que este distingue entre maysculas y minsculas. (l) Se recomienda instalar la Consola de Errores de Mozilla Firefox el componente Firebug para Firefox ya que con el uso de estas herramientas, el 99% de los problemas relacionados con Javascript y css se podrn encontrar fcilmente. (m)Hacer uso del ; al final de cada sentencia JavaScript para mejorar la lectura del cdigo (n) Evtiar colocar comentarios en los archivos css ya que hace ms lenta la transferencia y al usuario le parecer lenta la carga.
(o) En los css, se puede acortar el cdigo hexadecimal siempre y cuando cumpla con la regla de que los pares de colores RGB sean iguales. As, el color #1111FF se puede acortar como #11F. Lo que no se puede hacer es acortar este cdigo: #1244BB, ya que el primer par no es igual. Tampoco se puede acortar #CCCCCC a #C, sino que a #CCC.
7. Comentarios
(a) Documentacin de la Clase: Se coloca al comienzo del archivo y est compuesto por la licencia (en el caso que aplique), el nombre del autor, la fecha de creacin, versin y las modificaciones realizadas con el nombre de la persona y fecha (en caso que aplique). Se debe hacer uso del estndar de documentacin existente para el lenguaje en el que se est desarrollando. (b) Implementacin de la Clase: Este comentario va antes de la sentencia class, debe contener cualquier informacin aplicable a toda la clase (generalmente propsito y funcionalidades de la misma). (c) De mtodos/funciones: Se coloca antes de cada funcin o mtodo dando una breve descripcin de su funcionalidad, resaltando sus aspectos de mayor relevancia. (d) De variables: Se coloca antes de la declaracin de la misma. Este tipo de comentarios se realiza solo en casos que lo amerite. (e) En el cdigo: Solo se coloca antes del trozo de cdigo que necesite una aclaracin o explicacin. (f) No escribir comentarios si el cdigo es fcilmente comprensible sin los mismos. Al hacer uso correcto de los estndares de nombrado y uso de variables y mtodos, se disminuye la cantidad de comentarios en el cdigo. (g) Los comentarios de pocas lneas hacen el cdigo ms elegante. Sin embargo, es peor no tener comentarios en cdigo poco legible.
8. Manejo de Excepciones
(a) Nunca hacer captura de excepcin y no hacer nada. Si oculta una excepcin, nunca se podr saber si la excepcin que ocurri o no. (b) En el caso de que ocurra alguna excepcin, se debe dar un mensaje amigable al usuario, pero en el log de errores se debe contar con todos los posibles detalles sobre el error, incluyendo el momento en que ocurri, mtodo y nombre de clase, entre otros. Esto evita mostrar el vulnerabilidades a los atacantes. (c) No utilizar la sentencia try catch (captura de excepciones) en todos los mtodos de la clase. Se debe utilizar slo si existe la posibilidad de que una excepcin especfica puede ocurrir y no puede ser impedido por cualquier otro medio. Siempre se deben hacer las validaciones de datos correspondientes antes de esperar a que se produzcan excepciones. Por otra parte, siempre se debe realizar el manejo de excepciones cuando la aplicacin se comunica con sistemas externos, dispositivos de hardware, entre otros. El manejo de excepciones es importante para la captura de errores y para la reparacin de los mismos. (d) No escribir bloques try catch muy largos. De ser necesario, se debe separar en varios bloques try catch que contengan las tareas especficas realizadas por el sistema. Esto permitir identificar en qu trozo de cdigo se ha producido alguna excepcin y as dar un mensaje ms acertado al usuario.
9. Parametrizacin y Configuracin de una aplicacin

Si el lenguaje, herramienta o framework en el cual se basa la aplicacin no provee mecanismos por defecto para establecer configuraciones o parmetros, y nuestra aplicacin necesita definirlos, se deber utilizar XML como formato de archivos de configuracin. Estos archivos debern ubicarse en un directorio llamado conf, que estar ubicado en el directorio raz de la aplicacin.
10. Sobre la organizacin de una aplicacin a nivel de Sistema de Archivos

APP
|- admin (Seccin Administrativa) |- conf (Configuracin general de todos los mdulos) |- modulo_x (Nombre de la carpeta correspondiente a un mdulo. Ej: Noticias) |- models (Clases que encapsulan lgica de negocio y acceso a los datos) |- views (Programas que se encargan de la presentacin de la aplicacin al usuario final) |- css |- images |- inc |- js |- controlers (Programas que se encargan de gestionar las peticiones e invocar las vistas y modelos involucrados) |- public (Seccin Pblica) |- conf |- modulo_x
|- models |- views |- css |- images |- inc |- js |- controlers |- db (Todo lo referente a la base de datos de la aplicacin, como por ejemplo Scripts SQL, procedimientos de carga de datos, entre otros) |- lib (Libreras generales para toda la aplicacin) |- il8n (Libreras para el manejo de la internacionalizacin) |- logs (Archivos de Logs de la Aplicacin) |- tests (Pruebas Unitarias) |- docs (Documentacin de toda la aplicacin)
11. Sobre las Estructuras de Datos (Persistencia)

(a) Los nombres de las bases de datos deben ser lo ms explcitos posibles, evitar el uso de abreviaturas, a menos que sean de uso comn. Hay que mantener coherencia y consistencia en los nombres. (b) Toda tabla debe tener una clave primaria. Deben encontrarse un conjunto de datos (al menos uno) cuya combinacin permita identificar unvocamente las filas de una tabla o relacin. (c) Hay que elegir con sumo cuidado el tipo de atributos de las tablas (columnas), es recomendable usar el que requiera menos espacio de almacenamiento que aplique, y en caso que se necesite aumentar su rango, se usa la instruccin ALTER TABLE para cambiar o aumentar tipo previamente elegido (d) A la hora de seleccionar los ndices, se pueden seguir las siguientes indicaciones:

No crear ndices sobre relaciones pequeas. Aadir un ndice sobre los atributos que se utilizan para acceder con mucha frecuencia. Evitar los ndices sobre atributos que se modifican a menudo. Evitar los ndices sobre atributos poco selectivos (aquellos en los que la consulta selecciona una porcin significativa de la relacin). Evitar los ndices sobre atributos tipo caracteres de larga longitud. Los ndices creados se deben documentar, explicando las razones de su eleccin. Segn el manejador de Base de Datos utilizado, una clave fornea genera automticamente un ndice, si no lo hace debe crearse, para mejorar el rendimiento de las operaciones de interseccin entre las tablas relacionadas (JOIN).
A continuacin se presenta un cuadro con los estndares de nombres de los componentes involucrados en una base de datos:
Nombre
Reglas para nombrar
Ejemplos
Base de Datos
Los nombres deben estar en minscula, y en caso de ser palabras compuestas, estas se deben separar con un guin bajo registro_nic_db (_) , estar en singular y terminar con un db. Comenzar en minscula y con la letra t si son palabras compuestas, estas se deben separar con un guin bajo (_) y se escriben en plural. Utilizar la letra t nos t_personas permite distinguir rpidamente las t_instituciones_legales tablas entre los diferentes objetos que se almacenan en una bd. Se escriben en minscula y en singular. Si son palabras compuestas, estas se deben separar con un guin bajo (_). En caso que la columna sea clave (primaria o fornea) esta debe comenzar con la palabra id.
Tablas
Columnas
nombre nombre_profesor id_alumno id_estado
Clave Primaria
El nombre de la restriccin de la pk_id_alumno clave primaria debe comenzar con pk_id_recurso_noticia pk, seguida del nombre de la clave primaria. Si esta es una clave compuesta, las palabras deben separarse con un guin bajo (_) y deben colocarse de una manera clara y concisa.
Versin: 1.6 Revisado por: Yasibit Reao Aprobado por: Richard Perna
Estndares de Programacin Elaborado por: Danela Gutirrez, Ana Fernandes
Clave Fornea
El nombre de la restriccin de la clave fornea debe comenzar con fk, seguida del nombre de la clave fornea. Si esta es una fk_id_alumno clave compuesta, las palabras fk_id_recurso_noticia deben separarse con un guin bajo (_) y deben colocarse de una manera clara y concisa. El nombre de la restriccin del ndice debe comenzar por ix, seguida del nombre de la tabla y ix_t_alumno_id_alumno del nombre sobre el cual se crea el ix_t_alumno_id_recurso_noticia ndice.
ndices
12. Sobre la Seguridad

La seguridad de una aplicacin, especialmente en un ambiente de red, involucra aspectos que van ms all de la misma, como el uso de protocolos de cifrado, firewalls, configuracin de servidores web, sistema operativo, robustez o madurez del lenguaje de programacin, entre otros. Sin embargo, existen algunos aspectos propios de la forma de programacin que deben tomarse en cuenta: (a) Todas las pginas de uso administrativo deben ser referenciadas por otra (puede ser ella misma). En otras palabras, si a un programa C se llega solo desde los programas A y B, el programa C debe controlar esto. En ambientes web, esto se debe realizar utilizando el encabezado http: referer. (b) Validar los campos del formulario de manera adecuada para evitar tcnicas de ataque como SQL injection, como por ejemplo los caracteres ' y -- . (c) Utilizar funciones de escape para evitar ataques de SQL injection.
(d) Estar atentos al cross site scripting (XSS), validando los campos adecuadamente escapando caracteres especiales usados comnmente en HTML, tales como: <, >, &,#, entre otros. (e) Evitar en los formularios el pase de parmetros por el mtodo GET. (f) Evitar pasar a travs de un formulario informacin sensible por medio de parmetros ocultos (hidden). (g) Usar SSL en caso que lo amerite. (h) No colocar en el QUERY STRING datos de alta importancia (por ejemplo la clave del usuario), y de ser necesario por lo menos encriptarlos. 13. Recomendaciones Es necesario que alguna oficina fuera de la perteneciente al rea de desarrollo vele por la aplicacin de los estndares anteriormente descritos. Se recomienda que esta labor sea realizada por el personal de la Oficina de Calidad de Sistemas, considerando que ellos realizan una evaluacin desde el punto de vista de calidad de los desarrollos realizados donde se pueden incorporar mtricas asociadas a los estndares descritos. Este documento posee informacin bsica respecto a los aspectos de seguridad que deben considerarse en el momento de realizar desarrollos de sistemas, es necesario que esta seccin del documento sea ampliada por el personal de la Oficina de Seguridad, quienes son especialistas en esta rea.
14. Referencias Estndares: http://pear.php.net/manual/standards.php Mejores Prcticas: http://talks.php.net/show/php-best-practices/ http://www.slideshare.net/jesus.castagnetto/buenas-prcticas-deprogramacin-en-php-presentation


Estandares de Programacion - v1-6

Diunggah oleh

Informasi Dokumen

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Estandares de Programacion - v1-6

Diunggah oleh

Hak Cipta:

Format Tersedia

Estndares de Programacin CNTI

Versin: 1.6 Aprobado por: Richard Perna

1.2 1.3 1.4 1.5 1.6

20/10/11 24/10/11 25/10/11 28/10/11 25/11/11

Versin: 1.6 Aprobado por: Richard Perna

Versin: 1.6 Aprobado por: Richard Perna

Estndares de Programacin CNTI

2. Estndares y Convenciones de Nombre

Presidencia.html PresupuestoAnual.java RegistrarUsuario.php

Paquetes (cuando aplique)

Para el caso del CNTI podra ser: ve.cnti.genportal.plantillas

class Usuario class UsuarioAdministrador

Aprobado por: Richard Perna

ejecutar() agregarUsuario() function getPassword()

Revisado por: Yasibit Reao

Aprobado por: Richard Perna

float impuesto double totalSinIVA $montoConIVa

Deben ir totalmente en mayscula separando las palabras con un underscore (_)

Versin: 1.6 Aprobado por: Richard Perna

Versin: 1.6 Aprobado por: Richard Perna

DataList Checkbox RadioButton Image Panel Table

dtl chk rdo img pnl tbl

4. Buenas Prcticas de Programacin

Versin: 1.6 Aprobado por: Richard Perna

if ( ( a == b ) && ( c==d ) ) // OK if ( a == b && c==d ) // EVITAR

Versin: 1.6 Aprobado por: Richard Perna

Versin: 1.6 Aprobado por: Richard Perna

9. Parametrizacin y Configuracin de una aplicacin

10. Sobre la organizacin de una aplicacin a nivel de Sistema de Archivos

Versin: 1.6 Aprobado por: Richard Perna

Versin: 1.6 Aprobado por: Richard Perna

11. Sobre las Estructuras de Datos (Persistencia)

Versin: 1.6 Aprobado por: Richard Perna

Reglas para nombrar

nombre nombre_profesor id_alumno id_estado

Estndares de Programacin Elaborado por: Danela Gutirrez, Ana Fernandes

12. Sobre la Seguridad

Versin: 1.6 Aprobado por: Richard Perna

14. Referencias Estndares: http://pear.php.net/manual/standards.php Mejores Prcticas: http://talks.php.net/show/php-best-practices/ http://www.slideshare.net/jesus.castagnetto/buenas-prcticas-deprogramacin-en-php-presentation

Anda mungkin juga menyukai