estandares buenas practicas desarrollo de software

ESTANDARES Y BUENAS PRACTICAS DE DESARROLLO DE SOFTWARE

CORE BANK 1.5

Marzo – 2015

ESTANDARES Y BUENAS PRACTICAS DE DESARROLLO DE SOFTWARE CORE BANK 1.5

Revisión: 01Fecha:Código: EDS-SI

Contenido1. Objetivo.....................................................................................................................................5

2. Nivel de aplicación.....................................................................................................................5

2.1. Nomenclatura........................................................................................................................5

2.1.1. De proyectos......................................................................................................................5

2.1.2. De clases............................................................................................................................5

2.1.3. De Objetos y/o Controles..................................................................................................5

2.1.4. Nomenclatura de Las instancias de las clases y formularios............................................7

2.1.5. De los métodos en clases y formularios............................................................................7

2.1.6. De Variables.......................................................................................................................7

2.1.7. De Constantes....................................................................................................................9

2.1.8. Del Indentado....................................................................................................................9

2.1.9. De Editor de código............................................................................................................9

2.2. Uso de control de excepciones............................................................................................10

2.3. Liberación de cuentas..........................................................................................................10

2.4. Uso de imágenes en los controles.......................................................................................10

2.5. Uso clases de encriptación..................................................................................................10

2.6. Uso de Regiones..................................................................................................................11

2.7. Uso de Snippets...................................................................................................................11

2.8. Administración de plantillas en Visual Studio.....................................................................15

3. Nivel de Base de datos............................................................................................................20

3.1. Definición de objetos o tablas.............................................................................................20

3.2. Definición de campos..........................................................................................................21

3.3. Constraint e índices.............................................................................................................22

3.4. Vistas....................................................................................................................................23

3.5. Procedimientos almacenados.............................................................................................23

3.6. Triggers................................................................................................................................24

3.7. Declaración de variables en SQL..........................................................................................24

3.8. Uso de Proyectos en Sql Server Management....................................................................26

4. Estándares de codificación SQL Server....................................................................................29

4.1. Objetivo de la estandarización en la base de datos............................................................29

4.2. Convenciones de sintaxis de Transact-Sql...........................................................................29

Elaborado Revisado: Aprobado: Página

Alan Huanca Villaverde Comité revisor Vidal Egas Arroyo Página 2 de 42Confidencial: Está prohibida la reproducción total o parcial del contenido de este documento sin permiso de la empresa Soluciones Integrales ELS S.A.C. - SolIntELS. ©



5. Variables Globales del Core Bank............................................................................................37

6. Buenas Prácticas de Programación.........................................................................................38

6.1. Codificación..........................................................................................................................38

6.2. En la Base de Datos..............................................................................................................40





INTRODUCCION

El presente documento proporciona un nivel de estándares de desarrollo de sistemas, que permite

a los usuarios encargados de mantenimiento de los sistemas, cumplir adecuadamente sus

funciones bajo parámetros y lineamiento generales. Del mismo modo presentamos nomenclaturas

convencionales que conforman los Estándares para la programación y mantenimiento de la base

de datos. El uso de procedimientos y documentación estandarizada proporciona la base de una

comunicación clara y rápida, adiestramiento menos costoso del personal de sistemas, ayuda a los

analistas y diseñadores de sistemas en el trabajo de integración de sistemas, reducción de costos

de almacenamiento, entre otros.

Por lo crítica de esta documentación se debe revisar y actualizar permanentemente, ajustando a

las condiciones más convenientes para el desarrollo de sistemas.





1. ObjetivoEstablecer un marco de desarrollo único y de fácil aplicación al momento de implementar las aplicaciones realizar por la empresa.

2. Nivel de aplicación

2.1. Nomenclatura

2.1.1. De proyectosLa nomenclatura del proyecto a nivel de capas se define con la abreviatura del módulo y en la capa a la que pertenece. Como se muestra en la imagen Ejm: “CAJ.CapaNegocio” es el ejemplo del nombre del proyecto del módulo de caja en la capa de lógica de negocio.

“CAJ.AccesoDatos” es el ejemplo del nombre del proyecto del módulo de Caja en la capa de acceso a datos.

Cualquier proyecto que se adicione deberá ser del tipo ClassLibrary de a acuerdo a la versión del netframework (4.5) de la aplicación y el lenguaje de programación a seleccionar es C Sharp (c#).

2.1.2. De las clases La Clase es la estructura de un objeto, es decir, la definición de todos los elementos de que está hecho un objeto. Una clase se compone de dos partes atributos y Métodos.

La definición del nombre de las clases deberá iniciar con el prefijo “cls” de una clase, seguido por la abreviatura de la capa al cual pertenece mostrado en la tabla Nº 1, finalizando con el nombre de la clase. Donde la sintaxis quedaría de la siguiente forma: prefijo+Abreviatura+NombreClase.cls

Ejem1: La forma de nombrar una clase que pertenece a la capa de negocio encargado del cierre de crédito seria como sigue: inicia con “cls” la que indica que representa a una clase, continua con CN la que indica que pertenece a la capa de negocio, y finalmente el nombre de la clase CierreCredito. Dando como resultado el siguiente nombre: clsCNCierreCredito.cs

2.1.3. De Objetos y/o ControlesPara los nombre lógicos se debe evitar totalmente el uso de los nombres por DEFECTO cuando insertamos los controles y objetos en los formularios, dichos nombres deben ser cambiados tan pronto como se han adherido en los formularios, haciendo uso de los prefijos establecidos.



Tabla Nº 1. Abreviatura de claseAbreviatura Capa SintaxisCN Capa de negocio clsCNNombreClase.csAD Capa de acceso a datos clsADNombreClase.cs



Todos los objetos de los formularios deben tener el siguiente prefijo, seguidamente de la descripción del objeto tal como se mencionan los campos:

Tabla Nº 2GroupBox grbTextbox txtButton btnCombo box cboGridView dtgLabel (etiqueta) lblRadioButtonList rblCheckBox chbNumericUpDown nudPicture box pbxTabControl dtpDateTimerPicker tmrListView ltvUser control con

Ejemplos:cboAgencia Combo box para listar las agenciaschbCodOfi Check box para seleccionar los códigos de oficinatxtNroDocumento Textbox para recabar la información del Número

de documento.

Nombres FísicosEl Primer grupo de tres caracteres debe hacer referencia a las abreviaciones para identificación del objeto mostrada en la tabla Nº 3.Para asignar nombres a los formularios, programas, librerías, etc. deben tener el siguiente estándar:

Xxx Yyy Zzz Www N . ext

Donde:XXX Abreviación del objeto

Para el caso de un formulario seria frm (ver tabla de abreviatura de objetos físicos)

YYY primer detalle descriptivo.ZZZ segundo detalle descriptivoXXX tercer detalle descriptivo (opcional)N número que permite diferenciar dos programas idénticos (no es obligatorio).EXT Extensión que permite saber si es programa, formulario, librería, ejecutable, etc.





Ejemplo 1: frmDeclaracionMasivaSueldo.frmfrm Abreviación de objeto físicoDeclaracion primer detalle descriptivo.Masiva segundo detalle descriptivo.Sueldo tercer detalle descriptivo.

Tabla Nº 3 Abreviatura Objeto físicoNombre Prefijo Sintaxis

Formularios

frm frmNombreFormulario

Reportes rpt rptNombreReporteClases cls clsNombreClase

Ejemplo 2: el nombre de un formulario de apertura de cuenta estará compuesto de la siguiente manera, inicia con “frm” por tratarse de un formulario, seguido por el nombre del formulario que sería AperturaCuenta, quedado como nombre de formulario lo siguiente: frmAperturaCuenta

2.1.4. Nomenclatura de las instancias de las clases y formulariosAl crear una nueva instancia de una clase debe anteponerse las siglas de la capa a la que pertenece la clase, la nomenclatura deberá ser en letras minúsculas, por ejemplo:

Para la instancia de la clase clsADDeposito debe de ser: addeposito

Y para la clase clsCNCredito debe de ser: cncredito

Y para el caso de formularios de ser necesario su uso, deberá iniciar nombrarse con el mismo nombre pero con letras minúsculas, por ejemplo:

Para el formulario frmContenedorNue la instancia es: frmcontenedornue

2.1.5. De los métodos en clases y formulariosLos métodos y/o funciones que se declaran en las clases y formularios deberán seguir el siguiente formato:

- xxxYyy()Donde xxx: es la acción en verbo infinitivo, escrito en minúsculas.

Yyy: es el objeto sobre la cual se aplica la acción, escrito con la primera letra en mayúscula y a continuación en letras minúsculas.

Ejemplo:guardarCobranza()retornarSolicitud()





2.1.6. De VariablesLas variables vienen precedidas por una letra, la cual indica el tipo de variable que es. El nombre de la variable deberá ser significativo en relación a su significado y/o uso, utilizando palabras representativas, y comenzando de preferencia con una letra en mayúscula.Compuesta por las siguientes partes:

t Yyy Zzz Xxx ?t Prefijo de tipo de variable (todo en minúscula)Yyy 1ra. Descripción del campo. (1ra Letra en mayúscula)Zzz 2da. Descripción del campo.(1ra. Letra en mayúscula)? Nro. Adicional para diferenciar dos variables iguales

Tipos de Variables (t):

Tabla Nº 4c Carácterd Fechat Fecha y horan Numéricol Lógicog Generala Array (arreglos)

Ejemplos: cCodigoCliente, cCodigoCliente1, dFechaSistema

El uso de nombres como J, K, L, M,… debe restringirse a variables de control de ciclos (for K = 1), contadores cuyo significado resulte obvio.

Clasificación de VariablesPara asignar los prefijos y nombres las variables se clasifican de la siguiente manera:

Por alcance de las variables:Tabla Nº 5

Local, debe de declararse en un ámbito de un método.Global o publica, debe de declararse en la región de variables globales.

Públicas o Globales: Declaradas en la región de variables globales dentro de la clase.





Privadas o Locales: Variables que van a servir solo para uso local de formularios, programas o procedimientos y sus respectivos sub niveles en casos fuesen necesarios.

Ejemplos: cCuenta, lVigente

Ejemplo: dFechaNacimiento

2.1.7. De ConstantesNo deben de usarse constantes no nombradas. Las únicas constantes permitidas deben ser las obvias tal como 1 en “for j = 1 …”

2.1.8. Del IndentadoPor cada nivel de anidamiento se deberá contar con indentado por defecto proporcionado por Visual Studio.

2.1.9. De Editor de códigoLa fuente, tamaño, color, color de fondo, etc. Corresponderán a los que por defecto brinda Visual Studio.

2.1.10. De Comentarios.Los comentarios se realizaran a nivel de los métodos y funciones.Usar “//” para comentar en un renglón y para comentarios más amplios, usar el siguiente formato:

Ejm: /// <summary> /// Realiza una búsqueda de cliente por nombre /// Seguridad: Administradores /// </summary> /// <param name="nombre">Parte del nombre a buscar</param> /// <returns>Lista de clientes</returns>

2.1.11. De OperadoresTodos los operadores deben rodearse de un espacio antes y después del operador. Ejemplo A = A + B, los que por defecto brinda el .Net. al asignar el “;” al final.

2.1.12. De Llamadas a Sp’La Ejecución de Stores Procedures deberá realizarse a través de la clase objEjeSp y su método EjecSP. Además el envío de parámetros al SP deberá ser de forma implícita.Luego deberá ejecutarse el SP de la siguiente manera:





objEjeSp.EjecSP("GEN_InsSoliciAproba_SP", idAgencia, idCliente, nTipOper, idMoneda, idProducto, nMonto, idCuenta, dFecSolic, idMotivo, cSustento, dFecAprob, idUsuario);

2.1.13. De Messagebox

En el cuadro de mensaje, se debe de colocar un mensaje claro y conciso de lo que se quiere expresar. Como título de mensaje debe ir la descripción del proceso que se está ejecutando, de preferencia con un verbo dentro del título.

*Revisar el uso de CodeSnippets.

Utilizar los siguientes iconos para los casos especificados:

2.2. Uso de control de excepcionesLa arquitectura actual proporciona de manera genérica el control de excepciones al iniciar cada instancia de un formulario al ser llamado de manera dinámica desde el menú con la clase Exception, sin considerar el formulario de inicio y el formulario principal.

Solo en casos que justifiquen su uso explicito se procederá a implementar la sentencia:

try {} catch (ExceptionExplicit ex)

{}

2.3. Liberación de cuentasAl utilizar los controles de búsqueda de cuentas ya sea de créditos y/o depósitos, dichas cuentas quedaran bloqueadas automáticamente de manera lógica en el registro de la base de datos, por ello deberá implementar el método de liberación en los eventos de cierre de formularios.

2.4. Uso de imágenes en los controlesPara la creación de un nuevo botón deberá considerar un icono en formato “PNG” la cual deberá ser lo más descriptivo con respecto a la función que realizara. Las dimensiones son:

- Width : 24 px- Height : 24 px



Tabla Nº 6Icono Situación

Signo de exclamación.Titulo. ADVERTENCIA

Para avisar o consultar al usuario sobre algo inesperado, se puede dar la posibilidad de elegir entre varios botones.

Icono de información (i).Título: INFORMACION

Cuando se desea informar de un proceso concluido, o de una tarea ejecutada satisfactoriamente.



2.5. Uso clases de encriptaciónDeberá utilizar la clase clsCriptografia ya existente para la encriptación y desencriptación de cadenas, dicha clase podrá referenciarla desde el namespace “GEN.Funciones”.

Nota: Dicha clase es utilizada directamente ya que contiene método de tipo estático.

2.6. Uso de RegionesEn la codificación se debe usar las regiones para facilitar la lectura del código.Las regiones deben agruparse por los eventos, variables globales (Definición de Variables), métodos y funciones. Por ejemplo en la capa de presentación se dará de la siguiente forma:

Para la declaración de los namespaces se utilizara la región de directivas, tal como se muestra en la siguiente imagen.





2.7. Uso de SnippetsUn snippet es un bloque de código reutilizable que puede insertar donde sea necesario en el código.Ejemplo de un snippet:for (int i = 0; i < length; i++){

}

El ejemplo muestra el snippet para el bloque de código “for”, por conceptos de programación se sabe que el bloque de código se usa para un bucle repetitivo controlado por los parámetros indicados.

Creación de snippets para Visual Studio

Un Snippet es un archivo en formato xml con la extensión “.snippet”. Para crear nuestros propios snippets solo tendremos que crear un archivo xml con la siguiente estructura:

<?xml version="1.0" encoding="utf-8" ?><CodeSnippets xmlns="http://schemas.microsoft.com/VisualStudio/2005/CodeSnippet"> <CodeSnippet Format="1.0.0"> <Header> <Title>MensajeInfo</Title> <Shortcut>minfo</Shortcut> <Description>Code snippet para messageBox de información</Description> <Author>Alan Huanca Villaverde</Author> <SnippetTypes> <SnippetType>Expansion</SnippetType> <SnippetType>SurroundsWith</SnippetType> </SnippetTypes> </Header> <Snippet> <Declarations> <Literal> <ID>Mensaje</ID> <ToolTip>Mensaje a mostrar</ToolTip> <Default>Información ....</Default> </Literal> <Literal> <ID>Titulo</ID> <ToolTip>Titulo del mensaje</ToolTip> <Default>Titulo ....</Default> </Literal> </Declarations> <Code Language="csharp"> <![CDATA[MessageBox.Show("$Mensaje$", "$Titulo$", MessageBoxButtons.OK,

MessageBoxIcon.Information);]]> </Code> </Snippet> </CodeSnippet></CodeSnippets>





Los parámetros a configurar dentro del formato son los siguientes: Title: Es el título del snippet, generalmente indica la funcionalidad del bloque de

código que contiene el snippet. Shortcut: Es la abreviatura del snippet, y el nombres por el cual podremos llamar

al snippet en el IDE Visual Studio. Descripción: Descripción de la funcionalidad del bloque de código que contiene el

snippet. Author: Nombre del autor del snippet. SnippetTypes: Enumera los tipos de snippets, por defecto se colocaran los dos

tipos: Expansions y SurroundsWith. Declarations: Dentro de esta parte, se declararan los literales o partes del snippet

en que se podrán reemplazar con los valores que el desarrollador desee. Literal : Para declarar un literal, solo tendrá que agregar un elemento de tipo

“Literal”, dentro de este elemento, colocar un elemento ID, que será el identificador del literal, este deberá de ser único en el snippet. Además se debe agregar un elemento Tooltip, que será el texto que se mostrará como ayuda o descripción del snippet; por último agregar un elemento Default, que será el valor que asumirá el Literal por defecto.Podrá agregar tantos elementos Literal como desee.

Code: En este elemento se colocará el código del snippet, para hacer uso de un literal previamente declarado, solo bastará con ponerlo entre signos de dólar (Ejemplo: $Numero$).

Importación de Snippets a Visual Studio

Para importar los snippets creados a nuestro entorno de desarrollo que en este caso es Visual Studio, seguiremos los siguientes pasos.

1. Ingresar al Administrador de Snippets, por medio del menú Herramientas.

2. Seleccione el botón Importar, y busque la ubicación del snippet o snippets que quiere importar.





3. Por ultimo seleccione la carpeta a la que se agregaran los snippets.

Uso de Snippets en Visual Studio

Para hacer uso del snippet solo tiene que escribir el shortcut configurado al crear el snippet, y presionar dos veces la tecla TAB, a continuación el código referente al snippet se mostrará.





2.8. Administración de plantillas en Visual Studio

Visual Studio permite definir plantillas de archivos para agregar sobre algún proyecto, esto facilita a los desarrolladores a no tener que reescribir código repetitivo y comenzar con una base predefinida.Las plantillas pueden ser cualquier tipo de archivo soportado por Visual Studio, por ejemplo podremos crear plantillas de clases, formularios, archivos css, javascript, etc.

Creación de plantillasPara crear una plantilla, es necesario que usted generé el código que desee plasmar en la plantilla.





Para crear la plantilla a partir del archivo generado, ingrese al menú Archivo y a continuación al submenú Exportar plantilla





Seleccione la opción Item Template, luego selección el ítem que quiere convertir en una plantilla.

Si la plantilla requiere referencia seleccione las que sean necesarias.





Complete los datos de la plantilla, los datos solicitados serán el nombre de la plantilla, la descripción de la plantilla, un icono que identifique la plantilla, una imagen de vista previa de lo que generará el archivo, y por último se mostrará la ruta del archivo de salida, donde podrá buscar la plantilla.

La plantilla generada será un archivo comprimido en formato ZIP.

Agregar una plantilla a Visual Studio





Para agregar una plantilla deberá de ingresar al menu Herramientas y al submenu Opciones. Selecione la opcion Proyecto y soluciones y luego la opcion General.

Para poder usar las plantillas de usuario personalizadas, tiene dos opciones, la primera cambiar la ruta de la localización de las plantillas de usuario, o caso contrario agregar sus plantillas a la carpeta asignada por defecto.Luego de haber realizado alguna de las opciones, acepte los cambios.

Uso de plantillas en Visual StudioPara usar una plantilla previamente agregada, solo deberá agregar un elemento al proyecto, al hacer esto se mostrará la plantilla agregada.





Al agregar el elemento, podrá ver que se genera un archivo con el código de la plantilla agregada.





3. Nivel de Base de datos

3.1. Definición de objetos o tablas

Para la definición de una tabla se debe tener en cuenta el siguiente formato:

Tabla Nº 7SI_FIN T Xxx Yyy Zzz

(T) Debe identificarse qué tipo de tabla es:

M maestroT Tipos genéricosH HistóricoD Detalle (descriptivo)P PuenteW Tabla de Trabajo TemporalA Auditoria

(Xxx) Primera descripción de la tabla. (Abreviación)(Zzz) Segunda descripción de la tabla. (Abreviación)(Yyy) Tercera descripción de la tabla. (Abreviación)

Mínimo 6 caracteres

Ejemplo: SI_FinDReciboEgreso

Donde:

SI_Fin Prefijo de una tablaD DetalleRecibo Primera descripción de la tablaEgreso Segunda descripción de la tabla

3.2. Definición de campos

Los campos de las tablas deben al igual que las variables mantener las normas. Se tiene la siguiente descripción del armado de los campos.

t Yyy Zzz Xxx ?

t tipo de datoYyy 1ra. Descripción del campo. (1ra Letra en mayúscula)Zzz 2da. Descripción del campo.(1ra. Letra en mayúscula)Xxx 3ra. Descripción del campo. (1ra Letra en mayúscula)? Nro. Adicional para diferenciar dos campos iguales





Ejemplos: nNumeroDocumento

Donde:

n Prefijo del tipo de dato numéricoNumero Primera descripción del campoDocumento Segunda descripción del campo

La asignación de diccionario de datos será con la siguiente sentencia Sql:

GOEXEC sp_addextendedproperty @name = N'cVariable', @value = 'Nombre de la variable',@level0type = N'Schema', @level0name = 'dbo',@level1type = N'Table', @level1name = 'SI_FINVariable',@level2type = N'Column', @level2name = 'cVariable';GO

3.3. Constraint e índices

CONSTRAINT PRIMARY KEY (Clave Primaria)Estructura:

NombreTabla_NombreIndice_CPK

Ejemplo: SI_FinMCliente_CPKPK_SI_FinEstadoComprobante

CONSTRAINT FOREING KEY (Clave foránea)Estructura:

Nombretabla1_Nombretabla2_ NombreClaveForanea _CFK

Nombretabla1: Tabla OrigenNombretabla2: Tabla Destino

Ejemplo: SI_FinMCliente_SI_FinMMatricula_CFK

CONSTRAINT DEFAULTEstructura:

NombreTabla_NombreDefault_CDF

Ejemplo: SI_FinMCliente_SI_FinMMatricula_CDF

CONSTRAINT CHECKEstructura:





NombreTabla_NombreCheck_CCH

Ejemplo: SI_FinMCurso_cCodigoCurso_CCH

INDICES CLUSTEREDEstructura:

NombreTabla_NombreIndice_IXC

Ejemplo: SI_FinMRecibo_nNumRecibo_IXC

INDICE NONCLUSTEREDEstructura:

NombreTabla_NombreIndice_IXN

Ejemplo: SI_FinMRecibo_dFecEmiRec_IXC

3.4. VistasEstructura:

xxxNombreVista_Vis

xxx Abreviatura (SI_Fin) que corresponde a Core BankNombreVista Nombre corto de la vista

Ejemplo: SI_FinMDireccionCliente_Vis

3.5. Procedimientos almacenadosEstructura:

XXX_NombreSP_SP

Donde:

Xxx Abreviatura del módulo al que pertenece (ver tabla de módulos). Longitud 03 caracteres.

NombreSp Descripción del procedimiento almacenado. La descripción tiene 12 caracteres de longitud. Compuesto de la siguiente manera: XxxYyyZzzWww

SP Identifica que se trata de un procedimiento almacenado. (store procedure)

Tabla Nº 9. Tabla MódulosNombre AbreviaturaCREDITOS CREAHORROS(DEPOSITO) DEP





CAJA CAJCLIENTES CLICONTABILIDAD CNTRECURSOS HUMANOS GRHLOGISTICA LOGADMINISTRACION ADMSERVICIOS SERSPLAFT SPLREPORTES RPTCANALES ELECTRONICOS CNE

Ejemplo: ADM_InsertarProducto_SP

Los Stored Procedures deben nombrarse con prefijo “AbreviaturaModulo_”. NO usar nunca “sp_”, La razón porque: SQL Server reconoce el prefijo “sp_” como “System Stored Procedure”, es decir, un procedimiento almacenado de Sistema y lo buscaría en la BBDD “Master”.

3.6. Triggers

Estructura:xxx_yyy_NOMBRETABLA_TR

Donde:

XXX Nombre del móduloyyy Tipo de desencadenador (Upd, Ins, Del), o la combinación de los 3 casos.Nombre Tabla Nombre de la Tabla sin el indicador de aplicativo

Ejemplo: CRE_Upd_SI_FinMCliente_tr

3.7. Declaración de variables en SQLLas variables seguirán el patrón de estándares para la declaración de campos en tablas BD. Bajo las siguientes consideraciones:

Normas generales de nomenclatura

Los identificadores deben cumplir los siguientes requisitos:

El primer carácter del identificador debe ser una letra o uno de los siguientes símbolos _, @, # Los símbolos @ y # tienen un significado especial:

Un identificador comenzando con @ representa a una variable local.





Un identificador comenzando con # representa el nombre de un objeto temporal (Tabla o índice).

En caso de una tabla o stored procedure, el símbolo # representa a un objeto temporal local, y dos símbolos (##) representan a un objeto temporal global.Los nombres de los objetos temporales no deben exceder los 13 caracteres, incluyendo al # o ##, debido a que SQL Server les agrega un sufijo numérico interno.Los caracteres posteriores al primer carácter deben ser referidos básicamente a la descripción de la variable. Definiendo en tres palabras con la abreviación de cada una con 03 caracteres por palabra.Por defecto, no se aceptan espacios en blanco en medio de los identificadores; no obstante, su uso está permitido si se usan identificadores delimitados por comillas dobles. En el presente estándar, no se permiten los espacios en blanco como parte de un identificador.

Convenciones para nombres de variables

Todos los nombres de variables deben escribirse con una letra minúscula inicial seguido de un descriptor preferentemente referido a un campo, respetando los estándares y nomenclaturas:

<prefijo> <descripción> <variante>

Donde:

<prefijo> Prefijo del tipo de dato (01 carácter)<descripción> Descripción de la variable (09 caracteres)Preferentemente debe hacer referencia a los campos.<variante> Son números que marcan la diferencia de una a otra variable.

El prefijo debe representar el tipo de dato de la variable como se muestra en la siguiente tabla:

Tabla Nº 10.Tipo de Dato Tipo de dato de SQL

ServerPrefijo

Binary binary[(n)] bvarbinary[(n)] b

Character char[(n)] cvarchar[(n)] c

Date and time Datetime dsmalldatetime d

Exact numeric decimal[(p[, s])] nnumeric[(p[, s])] n

Approximate numeric float[(n)] n





Real nInteger Int n

Smallint nTinyint n

Monetary Money nsmallmoney n

Special Bit ltimestamp d

user-defined datatypes udt

Text and image Text tImageXml

Ix

En la medida de lo posible usar abreviaciones para variables según la tabla de abreviaciones (estas abreviaciones están incluidas el repositorio de estándares del proyecto).

3.8. Uso de Proyectos en Sql Server ManagementPara un control adecuado de los scripts generados durante el desarrollo se deberá hacer el uso de proyectos, los cuales nos proporcionan una adecuada gestión y mantenibilidad de los documentos en Sql Server Management, a continuación se describe los pasos a realizar:

a. Realizar la conexión al servidor de base de datos

b. Desde la barra de menú principal seleccionar la opción File/New/Project





c. Se mostrara la ventana donde se asignara el nombre del proyecto y su ubicación a almacenar dicho proyecto.

d. Una vez guardado, se mostrara la ventana “Solution Explorer” donde podrá visualizar la solución y el proyecto creado.





e. Dentro del proyecto se mostrara la carpeta Queries donde podrá agregar los archivos .sql

f. A nivel de cada Proyecto deberá mantener la siguiente estructura básica de archivos.





g. Las consideraciones para crear proyectos dentro de la soluciones son:- Un proyecto por cada requerimiento complejo.- Un proyecto si se ha de crear un nuevo módulo de la aplicación.- Un proyecto referido a un proceso del negocio

h. Para Agregar un nuevo proyecto de sql, hacer click derecho sobre la solución y seleccionar la opción a Add/New Project

i. A continuación deberá asignar el nombre del proyecto de acuerdo a lo requerido.

j. Finalmente podrá gestionar tantos proyectos que requiera dentro de una solución, siempre manteniendo el formato básico de los archivos.





4. Estándares de codificación SQL ServerTransact-SQL es fundamental para trabajar con Microsoft SQL Server. Todas las aplicaciones que se comunican con SQL Server lo hacen enviando instrucciones Transact-SQL al servidor, independientemente de la interfaz de usuario de la aplicación.

4.1. Objetivo de la estandarización en la base de datos

Hacer que el código sea más legible, claro y entendible, lo que a su vez permitirá asegurar un adecuado mantenimiento del mismo.

4.2. Convenciones de sintaxis de Transact-Sql

Para codificación de Procedimientos Almacenados (SPs), Funciones (FNc) y Vistas (VIs) se deberá cumplir con los siguientes estándares:

1. Para la creación y/o modificación de objetos como SPs, FNs y VIs se deberá tener el siguiente estándar:

a. Se deberá verificar si el objeto existe, de ser así, se procede con la eliminación del objeto para su posterior creación.

b. Los objetos deberán contener una cabecera donde se especifique los siguientes datos:

i. El Objetivo del código





ii. La Persona que escribió el código así algunos otros datos personales (email, móvil, etc.)

iii. La Fecha de Creación del objetoiv. El Sistema y Módulo para el cual se ha desarrollado el objeto v. Un historial de Modificaciones hechas al código

vi. Una Sintaxis de Ejemplo, que indica el modo básico de ejecución del objeto.

c. Luego de la cabecera se deberá escribir el código del objeto.d. Finalmente se deberá escribir los permisos requeridos para el objeto.e. La generación del script de creación de los objetos deberá realizarse con el

asistente de “Generación Sql Script” del MS SQL Server (se debe marcar siempre la opción: Script object-level permissions).

Ejemplo:

--ESTÁNDAR a.IF EXISTS (SELECT * FROM dbo.sysobjects where id = OBJECT_ID(N'[dbo].[dba_dbccreindex]') and OBJECTPROPERTY(id, N'IsProcedure') = 1)

DROP PROCEDURE [dbo].[dba_dbccreindex]GO

SET QUOTED_IDENTIFIER ON GOSET ANSI_NULLS ON GO

--ESTÁNDAR b./******************************************************************* * Copyright © 2012 SolIntELS SAC - All rights reserved. * * Objetivo : Registro de una Cobranza* * Escrito por : Vidal EGAS ARROYO * Email/Movil/Phone : [email protected] / #943616064* * Fecha creación : 2012/05/01 * * Sistema / Modulo : CRE * * Modificaciones: * Fecha Responsable Descripcion del cambio * 2012-08-29 glopez Insercion detalle de kardex

** Sintaxis de ejemplo: EXEC CRE_RegCobro_SP cadena,'2013/02/13' ,69 ,1 ,0 ,2241 ,1 ****************************************************************

****/ Elaborado Revisado: Aprobado: Página




--ESTÁNDAR c.

CREATE PROCEDURE [dbo].[CRE_RegCobro_SP]@XmlPlanPagoCobrado XML ,@dFechaSistema SMALLDATETIME ,@nUsuarioSis INT ,@nIdAgencia INT ,@nMoraPagada DECIMAL(14,2) , @cNroOpera VARCHAR(50)

AS BEGIN

SET NOCOUNT ON

<CODIGO>

ENDGOSET QUOTED_IDENTIFIER OFF GOSET ANSI_NULLS ON GO

--ESTÁNDAR d.GRANT EXECUTE ON [dbo].[CRE_RegCobro_SP] TO [ROL_FIN]GO

2. Para un adecuado control de las fechas de despliegue de los SPs, FNs y Vistas NO se admite modificaciones a los objetos con la sentencia ALTER.

3. Cuando se codifiquen SPs, la primera declaración que se debe escribir es SET NOCOUNT ON, pues mediante esta sentencia se minimiza el tráfico de red entre el Servidor SQL y las aplicaciones cliente.

Ejemplo:

CREATE PROCEDURE dba_dbccreindex @iScanDensIni SMALLINT,--valor del rango inicial del scan density a corregir@iScanDensFin SMALLINT,--valor del rango final del scan density a corregir@cFrecuencia CHAR(2),--frec. de ejecucion del mtto. (TD: todos los dias, DO: domingos)@cDb VARCHAR(50) --nombre de la BD a la que se hace el mentenimiento

AS

SET NOCOUNT ON





<CODIGO…>

4. Sólo se crearán SPs cifrados (opción WITH ENCRYPTION) si se justifica la protección del código contenido en estos.

Ejm:

CREATE PROCEDURE dba_dbccreindex @iScanDensIni SMALLINT,--valor del rango inicial del scan density a corregir@iScanDensFin SMALLINT,--valor del rango final del scan density a corregir@cFrecuencia CHAR(2),--frec. de ejecucion del mtto. (TD: todos los dias, DO: domingos)@cDb VARCHAR(50) --nombre de la BD a la que se hace el mentenimiento WITH ENCRYPTION

AS

SET NOCOUNT ON

<CODIGO…>

5. Sólo se crearán SPs para recompilación (opción WITH RECOMPILE) si se justifica la recompilación del plan de ejecución en la caché.Ejemplo:

CREATE PROCEDURE dba_dbccreindex @iScanDensIni SMALLINT,--valor del rango inicial del scan density a corregir@iScanDensFin SMALLINT,--valor del rango final del scan density a corregir@cFrecuencia CHAR(2),--frec. de ejecucion del mtto. (TD: todos los dias, DO: domingos)@cDb VARCHAR(50) --nombre de la BD a la que se hace el mentenimiento WITH RECOMPILE

AS

SET NOCOUNT ON

<CODIGO…>

6. Cuando se escriba código para SPs, es necesaria la utilización de la variable @@ERROR, pues esta variable retorna el código de error de la última sentencia Transact-SQL y permite un control sobre las excepciones que pudieran





presentarse en una transacción. Se debe chequear frecuentemente la variable @@ERROR, especialmente luego de sentencias de modificación de datos.Ejemplo:

BEGIN TRAN

INSERT authors(au_id, au_lname, au_fname, phone, address, city, state, zip, contract) VALUES ('409-56-7008', 'Bennet', 'Abraham', '415 658-9932', '6223 Bateman St.', 'Berkeley', 'CA', '94705', 1)

IF @@ERROR = 0BEGIN COMMIT TRANENDELSEBEGIN ROLLBACK TRANEND

Try catchGo to trataerror

7. Las palabras reservadas se deben escribir en mayúsculas.Ejemplo:

--LAS PALABRAS RESERVADAS SE ESCRIBEN EN MAYÚSCULASDECLARE @loginame SYSNAME SET @loginame = NULL

8. El identado consta de 4 espacios. El código debe identarse para que se identifique fácilmente una sentencia Transact-SQL dentro un bloque de código que realice una transacción específica. Es decir, el identado debe facilitar la lectura adecuada del código. Así mismo, debe minimizarse el ancho de las líneas escritas, puesto que líneas de código muy anchas tienden a ser menos entendibles.Ejemplo:

--IDENTADO en un bloque de códigoBEGIN TRAN

INSERT authors (au_id, au_lname, au_fname, phone, address, city, state, zip) VALUES ('409-56-7008', 'Bennet', 'Abraham', '415 658-9932','6223 Bateman St.', 'Berkeley', 'CA', '94705', 1)

IF @@ERROR = 0





BEGIN COMMIT TRAN

ENDELSEBEGIN

ROLLBACK TRANEND

9. También se debe identar las sentencias SELECT que contienen múltiples líneas.Ejemplo:

--IDENTADO en múltiples líneasSELECT e.emp_id, e.fname, e.lname, j.job_descFROM employee e

INNER JOIN jobs j ON e.job_id = j.job_id

WHERE e.hire_date > '1990-01-01'AND j.min_lvl >= 100

10. Para casos en que se tenga que usar sentencias CASE complejas, se deberán usar múltiples líneas para un mejor entendimiento del código.Ejemplo:

--CASE complejosSELECT

CASE regionWHEN 'WA' THEN 'Phil'WHEN 'WA' THEN 'Phil'WHEN 'WA' THEN 'Phil'ELSE 'Unknown'

END AS Salesman,CustomerID,CompanyName,ContactName

FROM CustomersORDER BY Salesman

11. No es necesario incluir dentro del código de los SPs la sentencia BEGIN/END puesto que es innecesario. La sentencia BEGIN/END debe usarse para los casos en que se requiera tener in flujo de control de ciertas sentencias. Siempre se debe alinear verticalmente la sentencia BEGIN con la sentencia END.Ejemplo:

--Uso de clausulas BEGIN/ENDIF @var = 1





BEGINPRINT '1'

ENDELSEBEGIN

PRINT 'not 1'END

12. Con la finalidad de tener código T-SQL más claro, se debe mantener un espacio horizontal entre los operadores ( “+”, “=”, “<>”, etc.) y demás código. También, se debe mantener un solo espacio entre las cláusulas T-SQL, columnas, etc.Ejemplo:

--Espacios horizontalesSELECT CustomerID, CompanyName, ContactNameFROM CustomersWHERE City <> 'Madrid'ORDER BY Salesman

13. Alias para columnas; en el caso de los alias para columnas se deberá mantener el siguiente estándar: ColumnName AS Label.Ejemplo:

--uso de alias para columnasSELECT

CASE regionWHEN 'WA' THEN 'Phil'WHEN 'WA' THEN 'Phil'WHEN 'WA' THEN 'Phil'ELSE 'Unknown'

END AS Salesman,CustomerID,CompanyName,ContactName

FROM CustomersORDER BY Salesman

14. Alias para tablas; para el caso de alias de tablas, se puede omitir la cláusula AS y por ende se puede escribir seguidamente a la tabla o vista el alias. Esto ayuda a distinguir los alias de columnas y de tablas. Cuando el “query” involucra al menos 2 tablas, vistas o funciones tipo tabla, se debe poner como prefijo de la columna el respectivo alias de la tabla.





Los nombres de los alias de tablas deberán ser las letras del alfabeto, y serán básicamente una abreviación o identificación única de la tabla.Para “queries” cortos sobre una sola tabla no se escriben alias.

Ejemplo:

--Alias de tablasSELECT E.emp_id, E.fname, E.lname, J.job_descFROM employee E

INNER JOIN jobs JON E.job_id = J.job_id

WHERE E.hire_date > '1990-01-01'AND J.min_lvl >= 100

15. Se deben listar las columnas afectadas por la sentencia INSERT, es decir cuando se realicen inserciones la lista de columnas afectadas por esta sentencia debe ser explícita. Ejemplo:

--Especificar claramente las columnas afectadas por la sentencia INSERTINSERT INTO miTabla

(codigo, nombre, apellido, puesto)SELECT e.emp_id, e.fname, e.lname, j.job_descFROM employee e

INNER JOIN jobs jON e.job_id = j.job_id

16. Cuando se crean TRIGGERS, se debe escribir la sentencia SET NOCOUNT ON dentro del código para minimizar tráfico de red. Otra razón para usar el SET NOCOUNT ON dentro de Triggers es porque los mensajes extras devueltos cuando se disparan desencadenadores (producto de la ejecución de algún código) puede causar resultados inesperados.

Ejemplo:

--Sentencia SET NOCOUNT ON dentro de TriggersCREATE TRIGGER AHO_Del_AHOMCuenta_TRON dbo.AHOMCuentaFOR DELETEAS

SET NOCOUNT ON

INSERT INTO AHOAMCuenta (cCodCuenta, cCodCliente, cCodTipCta, dFecApeCta, cCodUsuApe, cCodMoneda, nMonDepApe, nMonCheVal,





cAuditUser, dAuditDate, cAuditStation, cAuditClient, cModiUser, dModiDate, cModiStation, cModiClient, cAudTipCmd)SELECT

cCodCuenta, cCodCliente, cCodTipCta, dFecApeCta, cCodUsuApe, cCodMoneda, nMonDepApe, nMonCheVal, cAuditUser, dAuditDate, cAuditStation, cAuditClient,

ISNULL(SUSER_SNAME(), 'NT Trusted'), GETDATE(), HOST_NAME(), LEFT(APP_NAME(),50), 'D'FROM Deleted

17. Se debe evitar el uso de sentencias tipo SELECT *. El uso de “ * ” en sentencias SELECT resulta inadecuado puesto que el mantenimiento del código se hace más tedioso, además modificaciones en la estructura de la tabla pueden ocasionar errores o problemas de performance.

18. Comentarios. Se debe comentar aquel código ambiguo o difícil de entender, así como aquel código que es significativo e importante dentro del procedimiento. Se debe evitar sobre comentar así como dejar de comentar, puesto que comentarios en exceso hacen difícil de distinguir los comentarios importantes de los menos importantes, y en caso de dejar de comentar dificulta el mantenimiento y la identificación de procesos importantes.Los comentarios cortos deben estar precedidos de la cláusula:

--<comentario>Los comentarios que tengan más de una línea deben tener la siguiente cláusula: /*<comentario>*/

19. Especificar la creación de los cursores como de solo lectura

5. Variables Globales del Core BankLa relación de variables se encuentra en la tabla SI_FINMVariable con nombre maestro de Variables, de la Base de Datos de Negocio, las cuales tiene los siguientes campos:Cada vez que se va aumentando alguna variable esta se agrega en la tabla mencionada

Tabla 11. Variables GlobalesdFechaAct Fecha del SistemacURLReport Servidor ReportesnTipoCambio Tipo de CambionIGV Impuesto General a las VentasnMoraMinima Monto Mora MinimacRutaBackUp Ruta BackUp full Base de DatoscNomImpTer Nombre de la impresora térmicacNomEmpresa Nombre de La EmpresacNomCortoEmp Nombre Corto de La Empresa





Ojo: la notación a usar para el campo nombre en todo el proyecto es la Pascal donde el primer carácter de todas las palabras se escribe en Mayúsculas y los otros caracteres en minúsculas.

6. Buenas Prácticas de Programación

6.1. Codificación Para comparar dos strings se debe utilizar el String.Equal pasándole cómo

parámetro el StringComparison para evitar diferencias entre mayúsculas y minúsculas, así como también las diferentes culturas.

Utilizar String.Empty en lugar de en lugar de utilizar el carácter de comilla doble (“”).

Utilizar enum en donde sea requerido. No uses números o cadenas para indicar valores fijosEjemplo:

enum TipoCorreo{

Html,TextoPlano

}

switch ( tipoCorreo ){case TipoCorreo.Html://hacer algobreak;case TipoCorreo.TextoPlano:// hacer algo}

No utilizar código duro en rutas o letras de dispositivos. Esto deberá ser almacenado en la base de datos.

Un método debe tener solo “una tarea”. No combines más de una tarea en un solo método, aún si esas tareas son pequeñas.

Evitar escribir try-catch en todos sus métodos. Utilícelo sólo si hay una posibilidad de que una excepción específica se pueda producir y no se pueda evitar por cualquier otro medio. Por ejemplo siempre debe utilizar controladores de excepciones, si se comunica con sistemas externos, como de red, dispositivos hardware, etc. Estos sistemas están sujetos a fallos en





cualquier momento y la comprobación de errores no suele ser fiable. En esos casos, debe tratar de recuperarse del error.

Adoptar el paradigma Orientado a Objetos, con el paradigma orientado a objetos tenemos la ventaja de reutilizar código, todo esto con el fin de aprovechar al máximo los pilares de la programación orientada a objetos

Abstracción Encapsulación Herencia Polimorfismo Introspección Reflexión

Usa palabras entendibles y descriptivas para nombrar a las variables. No uses abreviaciones.

Correcto:string direccion;

int salario;

Incorrecto:string nom;string domic;int sal;

El nombre de los métodos debe decir lo que hace. No uses nombres engañosos. Si el nombre del método es obvio, no hay necesidad de documentación que explique qué hace el método.

Convierte las cadenas de texto a minúsculas o mayúsculas antes de compararlas. Esto asegurará que la cadena coincida.





Evita usar variables globales. Declara variables locales siempre que sea necesario y pásalas a otros métodos en vez de compartir una variable global entre métodos. Si compartes una variable global entre métodos, te será difícil rastrear qué método cambia el valor y cuando.

Las rutinas que controlan los eventos (event handlers) no deben contener el código que ejecuta la acción requerida. En vez de ello, llama a otro método desde la rutina controladora.

Nunca asumas que tu código se ejecutará desde el disco “C:”. No puedes saber si algunos usuarios lo ejecutan desde la red o desde “Z:”.

Evitar la procrastinación - “dejar para mañana lo que se puede hacer hoy." Básicamente, es no afrontar una tarea que tenemos pendiente, y que vamos retrasando horas, días o incluso semanas.

Escribe comentarios siempre que sea requerido. Pero un buen código requerirá muchos menos comentarios. Si todos los nombres de variables y métodos son entendibles, eso hará que el código sea muy legible y no necesitará muchos comentarios.

6.2. En la Base de Datos

Sé ACID (Atomicity, consistency, isolation, and durability) con los datosa. Atomicidad: es la propiedad que asegura que la operación se ha realizado

o no, y por lo tanto ante un fallo del sistema no puede quedar a medias.b. Consistencia: Integridad. Es la propiedad que asegura que sólo se

empieza aquello que se puede acabar. Por lo tanto se ejecutan aquellas operaciones que no van a romper las reglas y directrices de integridad de la base de datos.

c. Aislamiento: es la propiedad que asegura que una operación no puede afectar a otras. Esto asegura que la realización de dos transacciones sobre





la misma información sea independientes y no generen ningún tipo de error.

d. Durabilidad: es la propiedad que asegura que una vez realizada la operación, ésta persistirá y no se podrá deshacer aunque falle el sistema.

Considerar los campos de identificación y rastreo del registro tales como: un campo para la fecha y hora de inserción, un campo para la fecha y hora de modificación, un campo para el usuario que realiza la inserción, uno para el usuario que realiza la modificación.

Es recomendable, NO eliminar físicamente un registro de primeras. Pasarlo a un estado de “baja lógica” y posteriormente, en un proceso manual y/o automático (Data Garbage Collection), periódico, eliminarlo físicamente y/o pasarlo a un histórico.



estandares buenas practicas desarrollo de software

Documents