Tabla de ContenidoTabla de Contenido1. Introducción 4

2. Terminología y definiciones 4

3. Resumen ilustrativo 5

3.1 Tabla de descripciones 6

3.2 Convenciones de nombres 7

4. Convenciones de Nombres 10

4.1 Recomendaciones Generales 10

4.2 Uso de nombres y sintaxis 11

5. Estilo de Codificación 13

5.1 Formato 13

5.2 Comentarios 14

5.2.1 Comentarios de documentación 14

6. Uso del lenguaje 15

6.1 General 15

6.2 Variables y tipos 16

6.3 Control de flujos 17

6.4 Control de Excepciones 18

6.5 Eventos, Delegados e Hilos 18

6.6 Composición de Objetos 18

7. Consideraciones de Base de Datos 19

7.1 Índices 19

7.2 Escritura de sentencias SQL 19

7.3 Nombramiento de objetos de BDD 20

7.3.1 Nombres procedimientos y funciones 20

7.4 Documentación 21

8. Interfaz Gráfica 22

8.1 Tamaño de controles 22

8.2 Prefijos por cada control 22

8.3 Recomendaciones generales 23

9. Bibliografía 26

1) INTRODUCCIÓN

Este documento describe reglas y recomendaciones para el desarrollo de aplicaciones usando el lenguaje de la plataforma Microsoft.Net VB.Net. y su objetivo es definir líneas guías para enmarcar la consistencia de estilo y de formato para ayudar a los desarrolladores a evitar errores comunes. También se han incluido lineamientos y recomendaciones para el desarrollo de aplicaciones escalables y en capas.

Específicamente este documento cubre convenciones de nombres, estilos de codificación, uso de lenguaje, mejores prácticas para el desarrollo, etc. Todos estos temas son cubiertos detallando reglas y recomendaciones las cuales son aplicables para VB.NET.

2) TERMINOLOGÍA Y DEFINICIONES

La siguiente terminología es referenciada a través de este documento:

Modificador de Acceso

Es una palabra clave que se utiliza para declarar el nivel de accesibilidad de código que se tiene para las clases, métodos y atributos.

Ejemplo:

Private, Public, Friend, Protected, Shared.

Aunque los modificadores de acceso varían, las clases y la mayoría de sus miembros utilizan por defecto el modificador Private. Excepciones para esto son las interfaces y enumerados los cuales por defecto son públicos.

Camel Case

Forma de escribir una palabra donde su primera letra está en minúsculas, y la primera letra de las subsiguientes palabras en mayúsculas.

Ejemplo:

nombreEntidad, nombreProyectoEntidad.

Pascal Case

Forma de escribir una palabra donde su primera letra está en mayúscula, y la primera letra de las subsiguientes palabras igualmente en mayúsculas.

Ejemplo:

NombreMenu, NombreEstadoProyecto.

3) RESUMEN ILUSTRATIVO

Esta sección contiene cuadros y tablas describiendo los estándares de nombres, estilos de codificación y uso del lenguaje.

3.1) Tabla de descripciones

Propósito VB.NET

Programación Orientada a Objetos.

Construcción de una clase. Public Class miClase

Public Sub New{…}

MyBase.New

…

End Sub

…

End Class

Declaración de clase Class

Herencia de Clase Public Class A Inherits B

…

End Class

Nota: MustInherit, Indica que la clase solo puede ser heredada y no instanciada.

NotInheritable, Indica que la clase no puede ser heredada.

MyClass, Llamar a la propia implementación de un método en lugar de llamar al método sobre en una clase derivada.

MyBase, Referir a la clase padre de una clase derivada.

Declarar un delegado (Referencia segura a un método)

Delegate

Sobrescribir la implementación de un método o propiedad de una clase padre.

Overrides

Indicar que los métodos que no cuentan con implementación y que deben implementarse en clases derivadas.

MustOverride (En una clase declarada MustInherit)

Indicar que el método o propiedad no puede ser sobrescrita en clases derivadas.

NotOverridable

Indicar que el método si puede ser sobrescrito en clases derivadas

Overridable

Sobrecarga de procesos, funciones o métodos. Overloads

Definir una variable tipo objeto y con eventos para controlar.

WithEvents

Especifica el evento por el cual un método va a ser llamado.

Handles

Evaluar una expresión con el cual se tienen múltiples accesos a los miembros de un objeto.

With MiObjeto

<.Miembro>

<.Miembro>

End With

Referencia al objeto actual Me

Declaración de enums. Enum

…

End Enum

Declaración de una interfase Interface

Implementación de una interfase Implements

Indicador de índice Default Property

Modificador de Acceso a Clases

Indica que la clase es accesible fuera del proyecto o de su ensamblado.

Public

Indica que la clase es accesible solo dentro de su ensamblado.

Friend

Indica que la clase solo es accesible en el proyecto por clases anidadas dentro de esta clase.

Private

Modificadores de acceso de Miembros de una clase

Indica que el miembro es accesible fuera de la clase y del proyecto

Public

Indica que el miembro es accesible fuera de la clase pero no del proyecto.

Friend

Indica que el miembro solo es accesible en el ámbito de la clase.

Private

Indica que el miembro es accesible solo para la clase y para las clases derivadas.

Protected

Indica que el miembro es compartido a través de todas las instancias de la clase.

Shared

Otros

Indica comentario ‘,Rem

Indica constante Const

Creación de un nuevo objeto. New, CreateObject

Declaración de una función o método sin valor de retorno.

Sub

Declaración explicita de variables. Option Explicit

Declaración de eventos Event, RaiseEvent

Declaración de una estructura. Structure

…

End Structure

Declaración de objeto nulo. Nothing

Declaración de espacio de nombres. Namespace

…

End Namespace

Utilización de un espacio de nombres Imports

Devolver un carácter de una cadena literal. GetChar

Devuelve la dirección de una función. AddressOf

Prueba si un objeto es nulo. Obj Is Nothing

Bloqueo de Hilos. SyncLock

3.2) Convenciones de nombres

“C” = camelCase

“P” = PascalCase

“X” = No aplicable

Identificador Public Protected Friend Private Notas

Archivo Proyecto P X X X Coincidir con el Ensamblado y con el Espacio de Nombre (Namespace).

Archivo Fuente P X X X Coincidir con la clase que contiene.

Otros Archivos P X X X Aplicar cuando sea posible.

namespace P X X X Coincidir parcialmente el Proyecto/Ensamblado.

Clase o estructura.

P P P P Añadir sufijo de subclase.

Interfase. P P P P Añadir prefijo “ I ” mayúscula

Clase genérica P P P P Usar T o K como identificadores de tipo.

Método P P P P Usar un verbo o pareja verbo-objeto.

Propiedad P P P P No usar prefijos con Get o Set.

Campo P P P C Solo usar campos privados. No utilizar notación húngara.

Constante P P P C Solo usar campos privados.

Enumerador P P P P

Delegado P P P P

Evento P P P P

Parámetro X X X C

Variables Internas X X X C Evitar usar nombres de un solo carácter o de enumerados.

3.3) Palabras reservadas

Las palabras reservadas en un lenguaje son utilizadas por el compilador con fines específicos. Las cuales no se deben utilizar al momento de definir los nombres de los elementos del programa tal como variables y procedimientos.

Las siguientes palabras no son reservadas, pero de igual manera no deben ser utilizadas para el nombramiento de variables, procedimientos y otros elementos.

Aggregate Distinct IsFalse Preserve Unicode

Ansi Equals IsTrue Skip Until

Assembly Explicit Join Skip While Where

Auto From Key (Visual Basic) Strict #ExternalSource

Binary Group By Mid Take #Region

Compare Group Join Off Take While

Custom Into Order By Text

3.4) Estilos de codificación

Código Estilo

Archivo Fuente Un espacio de nombre por archivo y una clase por archivo.

Indentación Usar tabs de tamaño de 4 espacios en blanco.

Comentarios Utilizar ( ‘ ‘ ‘ ) para comentarios XML de las funciones y métodos.

Usar el ‘ para todo tipo de comentario.

Variables Una variable por declaración.

3.5) Uso del lenguaje

Código Estilo

Tipos nativos de datos Utilizar tipos de datos nativos de VB.NET en logar de los tipos del CTS de .NET

Ej. Utilizar Integer y no System.Int32

Propiedades Evitar utilizar prefijos Get o Set

MyBase Utilizar solamente en constructores o en sobrescritura.

Condicionales -Evitar evaluar condiciones booleanas contra true o false.-No utilizar asignaciones en la condición.

-Evitar usar invocaciones a métodos en las condiciones.

Excepciones Usar throw e; cuando se necesite relanzar excepciones.

Capturar solo cuando se vaya a manejar la excepción.

Usar validaciones para evitar excepciones.

Heredar siempre de la clase Exception.

Eventos Siempre chequear nulos antes de invocarlos.

4) Convenciones de Nombres

Esta sección está enfocada en el nombramiento de los proyectos, archivos de código fuente, e identificadores incluyendo campos, variables, propiedades, métodos, parámetros, clases, interfases y namespaces.

4.1 Recomendaciones Generales

1. Siempre usar nombres con estilo de escritura CamelCase o PascalCase (Ver tabla Sección 3.2).

2. Evitar nombres totalmente en MAYÚSCULAS o en minúsculas (a excepción de constantes de uno o dos caracteres). Nombres de una sola palabra serán totalmente en minúsculas si se utiliza el estilo de escritura CamelCase.

3. Nunca se deben crear namespaces, métodos, propiedades, campos o parámetros que varían solamente por su capitalización. (Mayúsculas)

4. No se deben utilizar nombres que inicien con caracteres numéricos.

5. Siempre se debe escoger nombres específicos y con significados en si mismos.

6. Variables y propiedades deben describir la entidad que representan no el tipo o tamaño.

7. No utilizar la notación húngara.

8. Evitar el uso de abreviaturas a menos que el nombre completo sea excesivo (25 caracteres).

9. Evitar el uso de underscore “_” y guión “-” en el nombramiento de métodos.

10. Evitar abreviaturas que su longitud sea mayor a 5 caracteres.

11. Cualquier abreviatura debe ser totalmente conocida y aceptada por el equipo de desarrollo.

12. Usar mayúsculas en caso de abreviaciones de 2 letras, y estilo de escritura PascalCase para abreviaturas mas largas.

13. Nunca usar palabras reservadas para nombres.

14. Evitar conflictos de nombres con los namespaces existentes o tipos existentes en el framework .Net

15. Evitar añadir redundancia en prefijos o sufijos de los identificadores

Ej. Public Enum ListaTiposRolEnum (TiposRol )

…

End Enum

16. Nunca incluir el nombre de la clase a los nombres de las propiedades.

Ej. Cliente.nombre en lugar de Cliente.nombreCliente

17. Tratar de utilizar los siguientes prefijos en las variables y propiedades booleanas, “Puede”, “Es”, “Tiene”.

18. Evitar la utilización de Boxing y UnBoxing, debido a que son procesos lentos

Ej. Dim obj As Object = New Point(1, 1) Dim valor As Int32 = Convert.ToInt32(obj)

19. En el nombramiento de métodos de una clase, se deben mantener nombres consistentes para métodos con operaciones similares, por ejemplo: Definir un método GuardarArchivo si tiene un método CargarArchivo, definir un método Cerrar si tiene un método Abrir

20. Los métodos no debe exceder en mas de 50 lineas ejecutables, es preferible dividir los métodos en varios procedimientos. Esto debido a que el compilador es mas eficiente compilando métodos menores a 32 bytes de código.

21. En el caso de tener métodos que tengan mas de 5 parámetros, es preferible utilizar estructuras o una clase.

22. Se debe evitar el código quemado o Hard-Code, mediante la utilización de un archivo de parámetros (De tipo property o XML).

23. El nombramiento del espacio de nombres debe utilizar el nombre de la compañía, seguido por el espacio de nombres y opcionalmente la característica de diseño, para evitar que existan dos espacios de nombres publicados con el mismo nombre.

Ejemplo. DNP.Datos.Formulacion DNP.Logica.Ejecucion DNP.Vista.Administracion

4.2 Uso de nombres y sintaxis

Identificador Convención de nombramiento

Archivo de Proyecto - Utilizar estilo de escritura Pascal Case

- Siempre coincidir el nombre del ensamblado y el espacio de nombres raiz.

Ej. Empresa.SistemaOnline.csproj -> Empresa.SistemaOnline.dll -> namespace: Empresa.SistemaOnline

Archivo Fuente - Utilizar estilo de escritura PascalCase

- Siempre coincidir el nombre de la clase y el nombre del archivo.

- Evitar incluir más de una clase, enumerador (global) o delegado (global) por archivo.

- Usar un nombre descriptivo para el archivo que contenga múltiples clases, enumeradores o delegados.

Ej. MiClase.vb => Public Class MiClase

Archivo de Recurso - Tratar de utilizar estilo de escritura PascalCase.

- Utilizar un nombre que describa la información que contenga el archivo.

Namespaces - Estilo de escritura PascalCase

- Tratar de coincidir el nombre ensamblado/proyecto.

Ej. Namespace Empresa.SistemaWeb

Clase o Estructura - Utilizar estilo de Escritura PascalCase.

- Usar sustantivo o frase de sustantivos para el nombre de la clase.

- Agregar un sufijo apropiado cuando se nombre sub clases.

Ej.

Private Class Miclase

…

End Class

Friend Class CoordenadaAttribute inherits Attribute

…

End Class

Public Class ClienteCollection inherits CollectionBase

…

End Class

Public Class ClienteEventArgs inherits EventArgs

…

End Class

Private Structure PropiedadesAplicacion

…

End Structure

Interfase - Utilizar estilo de escritura PascalCase

- Siempre agregar el prefijo “ I ”

Ej. Interface ICliente

…

End Interface

Método - Utilizar estilo de escritura PascalCase

- Tratar de usar un verbo o par verbo-objeto

Ej. Public Sub Ejecutar()

…

End Sub

Private Function ObtenerVersionEnsamblado(ByVal libreria As Assemble) As String

…

End Function

Propiedad - Utilizar estilo de escritura PascalCase

- El nombre de la propiedad debe representar la entidad que devuelve.

- Nunca utilizar los prefijos “Get” o “Set”.

- El nombre de la propiedad debe ser el nombre del atributo+ sufijo “Valor” (Ej: Property CodigoProyectoValor()).

Ej. Public Property Nombre() As String

Get

…

End Get

Set (ByVal Value As String)

…

End Set

End Property

Campo (Público, Protegido o interno)

- Utilizar estilo de escritura PascalCase.

- Evitar el uso de campos no privados.

- Usar propiedades en lugar de estos campos.

Ej. Public Nombre As String

Protected ListaInterna As IList

Campo (Privado) - Utilizar estilo de escritura tipo CamelCase.

Ej. Private nombre As String

Constante o campo estático - Tratar como un campo

Enumerador - Utilizar estilo de escritura PascalCase.

Ej. Public Enum TiposCliente

Normal

Frecuente

End Enum

Delegado o Evento - Se debe tratar como un campo

Ej. Public Event CargarComponente As EventHandler

Variable (Interna) - Utilizar estilo CamelCase.

- Evitar el uso de nombres de un solo carácter tales como “ x ” o “ y ” a excepción de aquellos utilizados en la sentencia for.

- Evitar enumerar nombre de variables como “cadena1”, “cadena2”,”cadena3”, etc.

Parámetro - Utilizar estilo de escritura PascalCase

Ej. Public Sub Ejecutar (ByVal Texto As String, ByVal Iteraciones As Integer)

…

End Sub

5) Estilo de Codificación

En esta sección se describe la manera de implementar código fuente en VB.NET de tal manera que sea un código legible, claro y consistente que sea fácil de comprender y mantener.

5.1) Formato

1. Nunca declarar más de un espacio de nombres por archivo.2. Evitar colocar múltiples clases en un mismo archivo.3. Declarar cada variable independientemente, nunca en la misma sentencia.4. Colocar la sentencia “imports” en la parte superior del archivo.

El grupo de los espacios de nombres de .NET deben ir por encima de los espacios de nombres particulares y todos ordenados alfabéticamente.

5. Agrupar la implementación interna de las clases en regiones por el tipo de miembros en el siguiente orden:

a. Campos (Atributos)b. Propiedadesc. Constructores y Destructoresd. Métodose. Enumeradores, Estructuras

6. Ordenar las declaraciones a partir de los modificadores de acceso y visibilidad:a. Privadosb. Internosc. Protegidosd. Públicos

5.2) Comentarios

1. Tratar de usar comentarios en el interior de los métodos para explicar aspectos globales del algoritmo (Ej: Declaracion de variables, código del método, registro de errores etc).

2. No utilizar comentarios para explicar código obvio.

3. Incluir lista de tareas para utilizar los filtros de comentarios

Ej. ‘TODO: Obtener cadena de conexión del registro.

5.2.1) Comentarios de documentación

Al inicio de cada objeto (Clase, Estructura, Interfase, Enumeracion, Delegado, Constante, Propiedad, Método) se debe agregar documentación técnica, utilizando los símbolos /// y las etiquetas que se describen a continuación.

EtiquetaDescripción En donde se utilizan Obligatorio

<c> Indica que el texto dentro de una descripción es código

<code> Indica que el texto consiste en varias líneas de código

Clase, Estructura, Interfase, Enumeracion, Delegado, Constante, Propiedad, Método

<example> Especifica un ejemplo para el miembro Clase, Estructura, Interfase,

Enumeracion, Delegado, Constante, Propiedad, Método

<exception>Especifica las excepciones que se pueden producir

Propiedad, Método

<include>Hace referencia a otro archivo que describe los tipos y miembros de su código fuente

<list> Define una lista o una tabla Clase, Estructura, Interfase,

Enumeracion, Delegado, Constante, Propiedad, Método

<para> Especifica que el contenido tiene el formato de un párrafo

Clase, Estructura, Interfase, Enumeracion, Delegado, Constante,

Propiedad, Método<param>

Define un nombre y descripción de parámetro Propiedad, Método<paramref>

Da formato a una palabra como un parámetro Propiedad, Método<permission>

Especifica un permiso necesario para el miembro

Constante, Propiedad, Método

<remarks> Especifica una sección de comentarios para el miembro

Clase, Estructura, Interfase, Enumeracion, Delegado, Constante, Propiedad, Método

X

<returns> Especifica el valor devuelto de la propiedad o función

Método X

<see>Especifica un vínculo a otro miembro Clase, Estructura, Interfase,

Enumeracion, Delegado, Constante, Propiedad, Método

<seealso>Especifica un vínculo que aparece en la sección Vea también de la documentación

Clase, Estructura, Interfase, Enumeracion, Delegado, Constante, Propiedad, Método

<summary> Especifica el resumen. Clase, Estructura, Interfase,

Enumeracion, Delegado, Constante, Propiedad, Método

X

<typeparam>Define un nombre y descripción de parámetro de tipo

<value>Especifica la descripción de una propiedad Propiedad X

A continuación se presentan las etiquetas de documentación que deben ser utilizadas para la generación del API con SandCastle.

Etiqueta Clase Estructura Interface Enum Variable

<summary> Obligatoria Obligatoria Obligatoria Obligatoria Obligatoria<remarks> Opcional Opcional Opcional Opcional Opcional<para> Opcional Opcional Opcional Opcional Opcional<example> Opcional Opcional Opcional<code> Opcional Opcional Opcional<see> Opcional Opcional Opcional<seealso> Opcional Opcional Opcional

6. Uso del lenguaje

6.1 General

1. Nunca utilizar la declaración explicita de variables con valor Off.

Ej. Option Explicit On

2. Tratar de utilizar la declaración implícita de conversión con valor On (el valor Off es por defecto).

Ej. Option Strict On

6.2 Variables y tipos

1. Tratar de inicializar las variables cuando se declaran (Ej: Inicializar las variables de tipo String a Empty).

2. Siempre utilizar los tipos de datos de VB.NET en lugar de los tipos del CTS de .NET

Ej. Utilizar Short, Integer, Long y String en lugar de System.Int16, System.Int32, System.Int64 y System.String

3. Solo declarar a los campos como privados. Usar propiedades para acceder a los campos privados utilizando los modificadores de acceso de tipo público, protegido o interno.

4. Evitar declarar variables de cadena de valores literales. En lugar de esto se deben usar constantes, recursos, registros de sistema u otro tipo de repositorio de datos.

5. Solo declarar constantes para tipos de datos simples, usando para constantes con uno o dos caracteres la mayúscula (Ejemplo: PI) y PascalCase cuanto tienen más caracteres (Ejemplo: DoublePI). Opcionalmente se usa todo el nombre en mayúscula para constantes privadas generalmente cuando se invoca una API (Ejemplo: WM_MOVE).

6. Siempre inicializar explícitamente los tipos referenciados en un arreglo al recorrer un bucle.

7. Evitar encapsular o desencapsular (boxing / unboxing) variables de tipo valor.

Ej: Dim fila As Integer = 1

‘Encapsulamiento implicito.

Dim objFila As Object = fila

‘Desencapsulamiento explicito

Dim nuevaFila As Integer = CType(objFila, Integer)

8. Es preferible utilizar StringBuilder en lugar de concatenación de cadenas.

9. No comparar cadenas a String.Empty o “” para verificar cadenas vacías. En su lugar, comparar por su longitud (String.Length) a cero.

10. Evitar la creación de cadenas ocultas en un bucle. Usar String.Compare() en su lugar.

Ej:

‘Este ejemplo está mal

Dim id As Integer = -1

Dim nombre As String = “Juan Perez”

For i As Integer = 0 To listaClientes.Count

If listaClientes(i).Nombre.ToLower() = nombre Then

Id = listaclientes(i).Id

End if

Next

‘Este ejemplo está bien

Dim id As Integer = -1

Dim nombre As String = “Juan Perez”

For i As Integer = 0 To listaClientes.Count

‘El argumento “ignoreCase” igual a True realiza una comparación

‘sin importarle la capitalización de las cadenas y sin alojar una nueva

‘cadena en memoria.

If String.Compare(listaClientes(i).Nombre, nombre, True) = 0 then

id = listaClientes(i).Id

End If

Next

6.3 Control de flujos

1. Evitar la creación de métodos recursivos. Utilizar bucle en su lugar.

2. Utilizar el operador condicional ternario solo para condiciones triviales. Evitar operaciones complejas con este operador (o condiciones triviales anidadas).

Ej. Dim resultado As Integer = IIf(esValido,9,4)

3. Evitar evaluar condiciones booleanas contra true o false.

Ej. If esValido = True Then ‘Mal

…

End if

If esValido Then ‘Bien

…

End If

4. Evitar expresiones condicionales complejas, usar variables booleanas para separar la expresión en expresiones manejables.

Ej. ‘Mal. If complejo y difícil de entender

If ((valor > Me.highScore) & (valor <> Me.highScore)) & (valor < Me.maxScore) Then

…

End if

‘Bien. If entendible

Dim esHighScore As Boolean = (valor >= Me.highScore)

Dim esEmpate As Boolean = (valor = Me.highScore)

Dim esValido As Boolean = (valor < Me.maxScore)

If (esHighScore And Not esEmpate) And esValido Then

…

End if

6.4 Control de Excepciones

1. No usar los bloques try / catch para control de flujos.

2. Solo capturar las excepciones cuando van a ser controladas.

3. Nunca declarar un bloque catch vacío.

4. Evitar anidar bloques try/catch en otro bloque catch.

5. Usar filtros de excepciones específicas.

6. Ordenar los filtros de excepciones de mas específica a más genérica.

7. Solo usar el bloque finally para liberar recursos utilizados en el bloque try.

8. Siempre utilizar validaciones para evitar excepciones.

9. Evitar definir excepciones personalizadas. Usar las clases de excepciones existentes.

10. Cuando una excepción personalizada es necesaria;

a. Siempre derivar de Exception no de ApplicationException

b. Siempre sobrescribir el método ToString().

c. Siempre sobrescribir el operador implicito string cuando se sobrescriba el método ToString().

La aplicación debe contar con un medio para la posterior consulta y revisión de los errores generados dentro de la aplicación, esta opción permite la depuración y afinamiento del código de una aplicación puesta en producción, por lo tanto es muy recomendable que el aplicativo cuente con un método para el almacenamiento y consulta de dicha información. Se recomienda que junto a la información del error se almacene la siguiente información:

Información Sugerida para el Control de Excepciones

Campo Descripción

Consecutivo Número consecutivo generado automáticamente.

Numero de Error Identificador del error generado por el compilador.

Descripción de Error Descripción del error generado por el compilador.

Módulo El módulo, método o clase desde el que se genera el error.

Usuario Usuario que genera el error o la excepción.

Fecha Fecha y hora del momento en que el error es generado.

Adicional Información adicional que se crea pertinente debe ser almacenada junto con el error o excepción.

Nota: La información de la tabla anterior es una sugerencia, recuerde que el objetivo es la de poder realizar seguimiento a los errores o excepciones generados, si usted tiene otra opción que permita realizar dicha tarea entonces no sería necesario implementar la propuesta en este documento. Se puede usar una mezcla de archivo de eventos y tabla de base de datos, ya que en el caso de no haber conexión con la BD obviamente el error no podrá ser grabado en una tabla.

6.5 Eventos, Delegados e Hilos

1. Siempre chequear que las instancias de los eventos y delegados sean diferentes a nulo.

2. Usar por defecto las clases EventHandler y EventArgs para los eventos más simples.

6.6 Composición de Objetos

1. Siempre declarar los tipos explícitamente con un espacio de nombres. Nunca usar el espacio de nombres por defecto “{global}”.

2. Evitar declarar métodos con más de 7 parámetros. Si fuera necesario considerar para una estructura o clase.

3. Solo usar la palabra reservada “base” o “MyBase” cuando se invoque en el constructor o implementación de una sobre escritura de algún método.

4. No usar el modificador de acceso Protected con NotInheritable.

5. Siempre llamar al método Close() o Dispose() en las clases que lo implementen.

7 Consideraciones de Base de Datos

1. No utilizar SELECT * por que el motor debe leer primero la estructura de la tabla antes de ejecutar la sentencia.2. Seleccionar solo aquellos campos que se necesiten, cada campo extra genera tiempo extra.3. Utilizar Inner Join, left join, right join, para unir las tablas en lugar del where, esto permite que a medida que se declaran

las tablas se vallan uniendo mientras que si utilizamos el where el motor genera primero el producto cartesiano de todos los registros de las tablas para luego filtrar las correctas, un trabajo definitivamente lento.

4. Especificar el alias de la tabla delante de cada campo definido en el select, esto le ahorra tiempo al motor de tener que buscar a que tabla pertenece el campo especificado.

5. Evitar el uso de case. Y formulas dentro de las consultas, cada formula y case retrasan el motor considerablemente.6. El orden de ubicación las tablas en el from deberían ir en lo preferible de menor a mayor según el número de registros, de

esta manera reducimos la cantidad de revisiones de registros que realiza el motor al unir las tablas a medida que se agregan.

7.1 Índices

Los índices son campos que permiten la búsqueda a partir de dicho campo a una velocidad notablemente superior. Sin embargo cuentan con la desventaja que hacen más lenta la actualización, carga y eliminación de los registros ya que por cada modificación en la tabla se deberá modificar también el índice, además se debe tener en cuenta el hecho de que los índices también ocupan espacio en disco. Es por esto que no es factible indexar todos los campos de la base y se hace necesario seleccionarlos cuidadosamente. Cabe destacar que por defecto las tablas no contienen índices por lo que la introducción de estos puede llegar a producir mejoras de más del 100% en algunos casos.

Los campos que se recomiendan indexar son:Claves PrimariasClaves ForáneasCampos por los cuales se realizaran búsquedasCampos por los cuales se va a ordenar

Siempre conviene indexar tablas con gran cantidad de registros y que van a ser consultadas intensamente.

7.2 Escritura de sentencias SQL

Para mayor entendimiento de las consultas SQL que se hagan a nivel de aplicación o de base de datos, es recomendable utilizar mayúsculas para el código SQL (palabras reservadas, SELECT, FROM, WHERE etc.). Separando una por cada línea las palabras reservadas SQL, y utilizando un nivel de indentación como se muestra a continuación:

Para formatear sentencias SQL extensas se puede utilizar el siguiente vínculo

http://www.wangz.net/cgi-bin/pp/gsqlparser/sqlpp/sqlformat.tpl

7.3 Nombramiento de objetos de BDD

7.3.1 Nombres procedimientos y funciones

Los nombres de los procedimientos o funciones deben ser:

Verbo infinitivo + palabras complementarias

Ej: CREATE FUNCTION ObtenerSaldoProyecto (@numeroProyecto float)RETURNS floatASBEGIN

.

. RETURN (saldo)END

CREATE PROCEDURE GenerarCodigoPresupuestal@HBPIN varchar(13)AS .

.

Código de base de datos

Objeto Prefijo Notación General Explicación

Disparadores (triggers)

trg_trg_NombreTabla_Funcionalidad

Un trigger para la tabla Clientes que se encarga de grabar la información de auditoría puede llamarse de la siguiente forma:

trg_Clientes_Auditoria

Índices idx_idx_[Tipo de Índice]Tabla_NombreCampo

Para el caso de los índices normales no se establece el tipo de índice, por ejemplo el índice para el campo Nombre de la tabla Clientes puede llamarse de la siguiente forma:

Índice Normal:idx_Clientes_Nombre

Para el caso de los tipos de índices diferentes al normal, se antepone un prefijo de dos letras en minúscula que permite su clasificación:

Índice basado en función:idx_fnClientes_CalculaEdad

Índices inversos (Reverse Key):idx_rkClientes_Cedula

Índices compuestos:idx_icClientes_NombreApellido

Índice Único:Idx_iuClientes_Login

Llave primaria pk_ pk_Tabla_Campo(s)

Para el caso de las llaves primarias formadas con muchos campos se puede usar un prefijo de tres letras para cada campo.

pk_Clientes_Cedula

Llave foránea fk_fk_TablaDestino_TablaFuente

Para visualizar las tablas implicadas en la relación, por ejemplo la tabla Clientes tiene una llave foránea vinculada al campo Independencia que viene referenciada de la tabla Dependencias, la relación puede llamarse de la siguiente forma:

Fk_Clientes_Dependencias

Vistas vw vwNombreVista

Los nombres de las vistas deben ser un nemónico que haga referencia a la tarea para la que fue creada, por ejemplo:

vwClientesPorDependencia

Vista materializada vm vmNombreVista Igual que para las vistas normales.

Chequeo chk_ chk_Tabla_Campo

Indica una restricción en esa tabla y campo, por ejemplo para indicar una restricción en el campo Estado de la tabla Clientes, la condición puede llamarse de la siguiente forma:

chk_Clientes_Estado

Job BD_ BD_Funcionalidad Para los Jobs de base de datos se requiere colocar como prefijo la base de datos a la que pertenece preferiblemente con un máximo de 6 caracteres, por ejemplo para la creación de un Job que se encarga de sincronizar los datos de la base de datos llamada SISDNP puede llamarse de la siguiente forma:

SISDNP_SincronizarTablas

Para el caso de un Job que realice tareas para diferentes bases de datos, se colocara solo el nombre del Job y puede llamarse de la siguiente

forma:

SincronizarTablas

Funciones F

FObtenerSaldoProyecto

El prefijo “F” permite identificar que el objeto de la base de datos es una función que retorna algún dato. Se debe escribir el nombre de la función con un verbo en infinitivo seguido de palabras complementarias.

Procedimientos P PRegistrarFuenteProyectoEl prefijo “P” indica que el objeto referenciado es un procedimiento almacenado de la base de datos.

Tablas - ProyectoVigencia Se debe utilizar el tipo de escritura PascalCase.

Campos - Vigencia Se debe utilizar el tipo de escritura PascalCase.

7.3.2. Nombramiento de Tablas

Estilo de escritura: Pascal Case.

Nombre:

Los nombres de las tablas deben estar asociados a la información que contiene, deben ser de fácil lectura y nemotécnicos.

Utilizar prefijo de tres letras por agrupación funcional (Por ejemplo: Cat, Seg. etc). En caso de utilizar algún tipo de agrupamiento en la base de datos se puede utilizar un prefijo de tres letras que permita

realizar dicho agrupamiento. Para el caso de las tablas de referencia (lookup) puede ser útil el uso de un prefijo que identifique las tablas como tal

(Ejemplo: TipoEstado). El tamaño máximo permitido por la base de datos es de 30 caracteres, aunque se sugiere que no pase de 12 o 14

caracteres para facilitar el uso de las mismas. En caso de utilizar diferentes esquemas en la base de datos se pueden emplear sinónimos con el fin de facilitar el uso de

las tablas. No es permitido el uso del carácter underscore (_). Escritura General de Tablas Sin Agrupamiento (Agrupamiento por funcionalidad o cualquier otro criterio):

<NombreTabla>

Ejemplo:

(Usuarios) Tabla para guardar la información de los usuarios de la aplicación.

Escritura General de Tablas Con Agrupamiento (Agrupamiento por funcionalidad o cualquier otro criterio):

<PrefijoAgrupamiento><NombreTabla>

Ejemplo:

(CatUsuarios) Tabla para guardar la información de los usuarios de la aplicación.

Escritura General de Tablas de Referencia (lookup):

<Prefijo><NombreTabla>

Ejemplo:

(TipoDocumento o TipoEstado) Tabla para guardar los tipos de documento o tipos de estado.

Escritura General de Tablas de Cruce:

<NombreTabla1><X><NombreTabla2>…

Ejemplo:

(UsuariosXDependencias) Tabla de cruce entre las tablas Usuarios y Dependencias, la tabla de cruce podría llamarse de la siguiente forma.

7.3.3. Nombramiento de Columnas

Nombre:

Los nombres de los campos deben estar asociados a la información que contiene, deben ser de fácil lectura y nemotécnicos.

Usar nombres descriptivos y lo mas cortos de ser posible, el objetivo es facilitar su lectura y proveer facilidad para su manejo.

Las llaves primarias de la tabla deben estar agrupadas al principio de la tabla y deben estar definidas en la base de datos como llaves primarias.

No se debe usar el alias de la tabla como prefijo para el nombramiento de las columnas. Para el caso de las llaves foráneas, estas deben llamarse de igual manera que la tabla a la que se hace referencia y debe

estar identificada como llave foránea en la tabla con su correspondiente relación con la tabla referenciada, en caso de ser posible. En raras ocasiones no se pude establecer dicha relación por diferentes motivos inherentes al diseño de la base de datos.

En la medida de lo posible y de ser necesario se deben usar restricciones de campo (Check Constraints o Null Constraints) para validar la información ingresada en los campos..

No es permitido el uso del carácter underscore (_).

7.3.4. Nombramiento de Sinónimos

Los nombres de los sinónimos deben ser equivalentes en la medida de lo posible a los nombres de los objetos que representan, omitiendo el esquema al que pertenece el objeto.

7.4 Documentación

Cada procedimiento, función, paquete en la base de datos, debe llevar una pequeña documentación al comienzo junto con un área para registrar las modificaciones que se realicen con el tiempo (antes del begin principal).

En los procedimientos y funciones que manejen parámetros, se debe escribir un parámetro por línea, y frente a cada uno se debe hacer una pequeña documentación de este.

Se debe documentar el código de los procedimientos y funciones, de manera que se logre entender fácilmente la funcionalidad de éstos. Bloques de programas grandes deben documentarse donde comienzan (debajo del begin) y donde terminan (antes del end).

Ejm:

CREATE PROCEDURE GenerarCodigoPresupuestal@HBPIN varchar (13) //codigo bpinAS

{FECHA CREACION: Octubre 1 de 2008 DISEÑO: Nro_doc_diseño AUTOR: Pedro Perez.

PROGRAMA: Generación de códigos presupuestales PARAMETROS: HBPIN Código BPIN del proyecto. MODIFICACIONES FECHA AUTOR CASO DE USO DESCRIPCION 15/10/2008 Pedro Perez Nro_caso_uso Se añade validación de codigo BPIN activo.

Además de la observación en el encabezado de la unidad principal, se debe documentar dentro del código los sitios donde se han realizado modificaciones, así:

// Autor fecha comentario breve

//PPEREZ 15/10/2008 Se añade consulta a la tabla historica de BPIN.

Toda variable y constante utilizada debe estar documentada, por esta razón se escribe una por línea.

Ej: codigoBPIN varchar(13); //Esta variable hace referencia al código completo concatenado nodo+consecutivo+subproyecto.

8. Interfaz Gráfica

Salvo algunas excepciones como es el caso de la estructura de las páginas y la ubicación del menú, las cuales fueron reubicadas para ampliar el área de contenido (o área de trabajo), como así lo solicitó el usuario del sistema. El grupo debe utilizar los estándares de la capa de presentación establecidos por la oficina de Informática, y que se encuentran en la siguiente ubicación:http://larebeca/Portals/0/archivos/documentos/TIC/Capa%20de%20Presentación%20-%20Guía%20General%20para%20Sistemas%20de%20Información.pdf

Otras consideraciones que se deben tener en cuenta son las siguientes:

8.1 Tamaño de controles

El alto de los controles debe ser de 20 ppi.

CONTROL ANCHO

Edit 2 caracteres 20 ppi

Edit 3 o 4 caracteres 50 ppi

Edit 5 a 8 caracteres y fechas sin hora 66 ppi

Edit 9 a 12 caracteres 100 ppi

Edit 13 a 16 caracteres 120 ppi

Edit 32 a 39 caracteres 232 ppi

Edit 40 a 64 caracteres

El edit de 40 puede ser de 232 cuando no afecte la funcionalidad

298 ppi

Listas (4 caracteres) 56 ppi

Listas (16 caracteres) 140 ppi

Botones de comandos 80 ppi

Los campos donde se capturen valores numéricos deben tener ancho especificado según el número de enteros y decimales que se maneje. Ancho sugerido 150 para campos numéricos 17,2.

8.2 Prefijos por cada control

8.3 Recomendaciones generales

1) Definir claramente los bloques de información, estableciendo marcos con ubicaciones fijas para el menú principal, el titulo y el cuerpo de la página.

Control Prefijo Ejemplo

Label lbl lblSurname

TextBox txt txtSurname

DataGrid dg dgResults

Button btn btnSave

ImageButton ibtn ibtnSave

Hyperlink lnk lnkHomePage

DropDownList ddl ddlCompany

ListBox lst lstCompany

DataList dlst dlstAddress

Repeater rep repSection

Checkbox chk chkMailList

CheckBoxList chk chkAddress

RadioButton rdo rdoSex

RadioButtonList rdo rdoAgeGroup

Image img imgLogo

Panel pan panSection

PlaceHolder plh plhHeader

Calender cal calMyDate

Adrotator adr adrBanner

Table tbl tblResults

Validators val valCreditCardNumber

ValidationSummary vals valsErrors

Ej: En páginas para filtrar información y mostrar el resultado de la consulta, se debe tener un bloque de parámetros y un bloque de resultados identificables.

2) Verificar que todos los encabezados, titulos y nombres de los controles hayan sido modificados de acuerdo a las recomendaciones, sin dejar el nombre por defecto.

3) Frente a cada caja de texto debe existir una etiqueta con una descripción clara y representativa que indique el dato que se debe introducir.

4) Se deben inhabilitar los controles, cuando el usuario no tenga los permisos suficientes para utilizar la página.

5) Los combos deben tener como maximo 25 valores, los cuales deben estar ordenados alfabéticamente de manera ascendente. (En los casos en que las listas de valores sean superiores a 25 valores, se deben utilizar controles de autocompletar o ventanas emergentes con opción de busqueda por parametros).

Se debe verificar que el control tenga la longitud del maximo valor posible (para evitar redimensión del control y de la página, lo cual genera barras de desplazamiento).

6) Utilizar los mismos colores en todas las páginas.

7) Los íconos utilizados deben cumplir en todas las páginas la misma función (Ej: no se debe tener un icono para imprimir en una página y en otra página el mismo icono para consultar).

8) En campos de fecha, se deben tener siempre el mismo formato de fecha. (Ej: DD-MM-YYYY y validar que no se ingresen fechas en otros formatos).

9) Las dimensiones de las páginas deben ser iguales. (Width y Height)

10) Todos los controles en el cuerpo de la página deben estar alineados (Ej: Todos los controles deben estar alineados a la izquierda o derecha, pero no en ambas alineaciones).

11) Todos los controles utilizados para ingresar datos o seleccionar datos, deben tener Tooltips que describa el dato a ingresar.

Bibliografía

- Design Guidelines for Class Library Developers http://msdn2.microsoft.com/es-es/library/czefa0ke(VS.71).aspx

- Guidelines and Best Practices http://msdn2.microsoft.com/es-es/library/ms184412.aspx

- Best Practices http://msdn2.microsoft.com/es-es/library/ms184411(VS.80).aspx

- Instant SQL Formatter http://www.wangz.net/cgi-bin/pp/gsqlparser/sqlpp/sqlformat.tpl

- Buenas Prácticas de Codificacion , Estandar de codificación y documentación de codigo fuente para aplicativos informáticos, Guia rápida del estandar de codificación y documentación de código fuente para aplicativos

informaticos http://larebeca/GestióndeTIC/LineamientosTécnicos/SistemasdeInformación/LineamientosTécnicosSI/tabid/724/Default.aspx