CRITERIOS DE CODIFICACION Los trminos Pascal Casing y Camel Casing son utilizados a lo largo de esta seccin.

Pascal Casing: Establece que el primer carcter de todas las palabras se expresa en mayscula y el resto de los caracteres en minscula, por ejemplo: CustomerOrder. Camel Casing: Define que el primer carcter de todas las palabras, excepto la primera palabra se expresa en mayscula y el resto de los caracteres en minscula, por ejemplo: customerOrder. NOMENCLATURA 1. Se deber utilizar Pascal Casing para los nombres de clases y para los nombre de los mtodos

2. El nombre del archivo debe coincidir con el nombre de la clase y debe respetar la notacin Pascal Casing. 3. Se deber utilizar Camel casing para nomenclar variables y parmetros de mtodos.

4. Se deber utilizar Pascal Case para nomenclar constantes. 5. Se deber utilizar Pascal Case para nomenclar enumerados y su nombre debe estar expresado en forma singular (de igual forma estn definidos en el .net framework). Cada miembro del enumerado deber tambin ser nomenclado utilizando Pascal Case y deber siempre tener un valor asignado explcitamente.

6. Utilizar el prefijo I con Pascal Casing para nomenclar Interfaces ( Ejemplo: IUser) 7. No se debe anteponer ningn prefijo que represente el tipo de datos de variables o constantes.

8. No utilice caracteres de subrayado (_) para nombres de variables locales. 9. Todas las variables de miembros deben estar precedidas por el carcter de subrayado (_) de modo que puedan diferenciarse de otras variables locales. 10. Utilizar prefijos como is o similares al nombrar variables de tipo bool. private bool isFinished; 11. Evite los nombres completo de tipo, en su lugar utilice la instruccin using. 12. Con los genricos, use maysculas para los tipos.

13. Se debe respetar el siguiente patrn de nomenclatura para los elementos de interfaz de usuario, de modo que se les pueda diferenciar del resto de las variables. Se agregar un prefijo que referencie al tipo de control que se nomencla, segn la siguiente lista:

14. Evite casting explicito. Use el operator as para defensivamente castear un tipo. IDENTACIN, ESPACIADO Y AGRUPACIN DE CDIGO

1. Utilice TAB de 4 posiciones para identar cdigo. No utilice espacios.

2. Los comentarios deben estar en el mismo nivel que el cdigo, es decir que han de utilizar el mismo nivel de identacin. 3. Las llaves de apertura y cierre deben estar en el mismo nivel que el cdigo fuera de stas. 4. Utilice una lnea en blanco para separar grupos lgicos de cdigo.

5. Una nica lnea en blanco debe separar un mtodo de otro, dentro de una clase. 6. Las llaves deben estar en una lnea independiente y no en la misma lnea que if, for, etc. 7. Utilizar un nico espacio antes y despus de cada operador, as como tambin entre trminos utilizados durante la invocacin de mtodos.

8. Mantener las variables de miembro, propiedades y mtodos en la parte superior del archivo, y miembros pblicos en la parte inferior del mismo. 9. Utilizar #region para agrupar piezas de cdigo relacionadas. Si se utiliza la agrupacin adecuada mediante #region, una clase o pgina deber lucir solamente con las regiones cuando todas las definiciones se contraigan. Mantener las variables miembro privadas, las propiedades y mtodos privados en la parte superior del archivo y los miembros pblicos en la parte inferior.

COMENTARIOS Comentarios correctos y significativos hacen al cdigo ms mantenible, sin embargo, se han de seguir los siguientes lineamientos: 1. No comentar todas y cada una de las lneas de cdigo ni cada variable declarada. 2. Utilizar // o /// para introducir comentarios. Evitar usar /* */ con comentarios de bloque. 3. Escribir comentarios donde sea requerido. Tener en cuenta que el buen cdigo legible requerir de pocos comentarios. Si todas las variables, mtodos, constantes tienen nombres significativos, esto har que el cdigo sea fcilmente legible y no requiera de la introduccin de comentarios en exceso. 4. No escribir comentarios en porciones en las que el cdigo es fcilmente entendible y no requiere de conocimiento especfico para su comprensin. 5. Si se debe utilizar lgica de negocio, se debe documentar correctamente con suficientes comentarios. 6. Si se inicializa una variable a un nmero especial distinto de 0, -1, String.Empty o Null, se deber documentar la razn por la que se ha escogido dicho valor. 7. Corroborar ortografa, gramtica y semntica de los comentarios, asegurndose de que la puntuacin es utilizada correctamente. 8. Agregar la documentacin del encabezado de cada mtodo (utilizando ///), especificando correctamente: El propsito del mtodo Nombre, Tipo de datos y Contenido de cada parmetro recibido

 El propsito de la informacin retornada Esto es particularmente til para generar documentacin de forma automtica, a partir de estos comentarios.

ASP.NET

1. No utilice las variables de sesin a travs del cdigo. Utilice variables de sesin slo dentro de clases y proporcione mtodos para acceder al valor almacenado en estas variables. Una clase puede tener acceso a las variables de sesin mediante System.Web.HttpCOntext.Current.Session. 2. No guarde objetos de gran tamao en la sesin. Esto puede consumir gran cantidad de memoria del servidor en funcin del nmero de usuarios. 3. Siempre use una hoja de estilo para controlar la apariencia de las pginas. Nunca especificar el nombre de fuente y tamao en ninguna de las pginas. Utilice clases de estilo. Esto le ayudar a cambiar la interfaz de usuario de su aplicacin fcilmente en el futuro. As, si usted desea personalizar la interfaz de usuario, slo es cuestin de desarrollar una hoja de estilos nueva. MANEJO DE EXCEPCIONES 1. Nunca capturar una excepcin y no hacer nada. Si se oculta una excepcin, nunca se sabr si la excepcin sucedido. Muchos desarrolladores utilizan este mtodo para ignorar errores no significativos. Trate de evitar las excepciones comprobando todas las condiciones de error mediante programacin. En el peor de los casos, usted debe registrar la excepcin en un log y continuar.

2. En casos de excepcin, mostrar un mensaje amigable al usuario, pero se debe logear la excepcin actual con todos los detalles posibles sobre el error, incluyendo el momento en que ocurri, el mtodo y nombre de la clase, etc. Siempre capturar una excepcion especifica, no genricas. Cuando vuelva a lanzar una excepcin, utilice la instruccin throw sin especificar la excepcin original. De esta manera, la llamada original conserva la pila.

4. No escriba try-catch en todos sus mtodos. Utilcelo slo si hay una posibilidad de que una excepcin especfica se puede producir y no se puede evitar por cualquier otro medio. Por ejemplo, si desea insertar un registro en la base de datos. Algunos desarrolladores tratan de insertar un registro sin comprobar si ya existe. Esto est estrictamente prohibido. Siempre debe comprobar si hay errores de forma explcita en lugar de esperar que se produzcan excepciones. Por otro lado, siempre debe utilizar controladores de excepciones, si se comunica con sistemas externos, como de red, dispositivos hardware, etc. Estos sistemas estn sujetos a fallos en cualquier momento y la comprobacin de errores no suele ser fiable. En esos casos, debe tratar de recuperarse del error. 5. No escriba bloques try-catch muy grandes. Si es necesario, escribir por separado try-catch para cada tarea de realizar e incluya slo la parte especfica del cdigo dentro del try-catch. Esto le ayudar a encontrar el cdigo que genera la excepcin y se puede dar mensaje de error especfico al usuario. 6. Escriba sus propias clases excepcin si se requiere en la aplicacin: Heredar de Exception, o de otra clase base propia El nombre de la clase culminarlo con Exception Considerar proveer propiedades adicionales. TESTING UNITARIO Cada una de las operaciones desarrolladas deber contar con tantos test unitarios como escenarios de prueba se deseen. Creacin de test unitarios Cada test unitario deber ser creado bajo la carpeta ProjectoName\Tests, y categorizado (en la forma de proyecto) en funcin del mdulo al que corresponda. A su vez, dentro de cada proyecto de test, se deber crear una carpeta con el mismo nombre del proyecto en el que se encuentra la clase para la cual se desea crear el Test. Cada archivo correspondiente a un test unitario, deber ser nomenclado respetando el siguiente patrn: UnitTest + [Nombre Clase que se testea] Cada nombre de mtodo cumplir con la forma Test_ + [Nombre Mtodo] + [Descripcin de Entrada] Ejemplos: Los test unitarios correspondientes al mdulo de Customers, debern ser colocados bajo la carpeta ProjectoName\Tests en el proyecto Customers.

Si se desea verificar el mtodo ValidateCustomer de una clase de nombre CustomerServices, correspondiente al mdulo Customers se seguirn los siguientes pasos: Se crear la clase UnitTestCustomerServices y se ubicar en Projecto\Tests\Customers. Dentro de la clase antedicha, se crear el mtodo de Test_ValidateCustomer_InvalidNumbers. Se agregar cdigo para verificar que la validacin de clientes opera de acuerdo a lo esperado cuando recibe ingresos no vlidos. Alcance de la validacin Cada mtodo de validacin que sea creado debe contemplar los casos que se tracen como posibles escenarios de ejecucin vlidos, incluyendo casos de borde. Organizacin de Tests Para cada mdulo de la solucin se deber crear una Test List (Men Test, Create Test List) que incluya todos los test asociados al mdulo. Esto permitir que los mismos sean administrados de forma conjunta. Prcticas recomendadas 1. Evitar crear dependencias entre tests que impliquen que deban ser ejecutados en un orden particular. Cada test unitario debe ser independiente. 2. Asegurarse de que los tests cubren todas las operaciones definidas en cada servicio. 3. Crear una clase de test para cada una de las clases que se desean verificar. Esto simplificar la organizacin de los tests y facilitar la tarea de seleccionar la ubicacin de cada uno de ellos. 4. Evitar crear tests que involucren informacin especfica del equipo, como por ejemplo versiones de software, tipo de arquitectura de procesador, rutas de acceso. 5. Ejecutar absolutamente todos los test desarrollados, cuando se realojen cambios, antes de hacer check-in y previo al empaquetado de una nueva versin.