You are on page 1of 7

CRITERIOS DE CODIFICACION Los términos “Pascal Casing” y “Camel Casing” son utilizados a lo largo de esta sección.

Pascal Casing: Establece que el primer carácter de todas las palabras se expresa en mayúscula y el resto de los caracteres en minúscula, por ejemplo: CustomerOrder. Camel Casing: Define que el primer carácter de todas las palabras, excepto la primera palabra se expresa en mayúscula y el resto de los caracteres en minúscula, por ejemplo: customerOrder. NOMENCLATURA 1. Se deberá utilizar Pascal Casing para los nombres de clases y para los nombre de los métodos

2. El nombre del archivo debe coincidir con el nombre de la clase y debe respetar la notación Pascal Casing. 3. Se deberá utilizar Camel casing para nomenclar variables y parámetros de métodos.

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 están definidos en el .net framework). Cada miembro del enumerado deberá también ser nomenclado utilizando Pascal Case y deberá siempre tener un valor asignado explícitamente.

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

12. Todas las variables de miembros deben estar precedidas por el carácter de subrayado (_) de modo que puedan diferenciarse de otras variables locales. IDENTACIÓN. 13. No utilice caracteres de subrayado (_) para nombres de variables locales. Utilice TAB de 4 posiciones para identar código. Evite casting explicito. de modo que se les pueda diferenciar del resto de las variables. private bool isFinished. 10. 9. Se agregará un prefijo que referencie al tipo de control que se nomencla. Use el operator as para defensivamente castear un tipo. 11. Con los genéricos. Utilizar prefijos como “is” o similares al nombrar variables de tipo bool.8. según la siguiente lista: 14. No utilice espacios. Se debe respetar el siguiente patrón de nomenclatura para los elementos de interfaz de usuario. use mayúsculas para los tipos. Evite los nombres completo de tipo. en su lugar utilice la instrucción using. ESPACIADO Y AGRUPACIÓN DE CÓDIGO 1. .

las propiedades y métodos privados en la parte superior del archivo y los miembros públicos en la parte inferior. 3. 7. Si se utiliza la agrupación adecuada mediante #region. es decir que han de utilizar el mismo nivel de identación. Utilizar un único espacio antes y después de cada operador. propiedades y métodos en la parte superior del archivo. 6. etc. Los comentarios deben estar en el mismo nivel que el código. así como también entre términos utilizados durante la invocación de métodos. 4. 5. Las llaves deben estar en una línea independiente y no en la misma línea que if. 9. y miembros públicos en la parte inferior del mismo. Mantener las variables de miembro. . Utilice una línea en blanco para separar grupos lógicos de código. 8. dentro de una clase. Utilizar #region para agrupar piezas de código relacionadas. Mantener las variables miembro privadas. for. Las llaves de apertura y cierre deben estar en el mismo nivel que el código fuera de éstas.2. Una única línea en blanco debe separar un método de otro. una clase o página deberá lucir solamente con las regiones cuando todas las definiciones se contraigan.

Escribir comentarios donde sea requerido. Evitar usar /* … */ con comentarios de bloque. esto hará que el código sea fácilmente legible y no requiera de la introducción de comentarios en exceso. Si se debe utilizar lógica de negocio. No comentar todas y cada una de las líneas de código ni cada variable declarada. gramática y semántica de los comentarios. No escribir comentarios en porciones en las que el código es fácilmente entendible y no requiere de conocimiento específico para su comprensión. Tener en cuenta que el buen código legible requerirá de pocos comentarios. 5. Agregar la documentación del encabezado de cada método (utilizando ///). métodos. especificando correctamente: • El propósito del método • Nombre. Utilizar // o /// para introducir comentarios. Corroborar ortografía. constantes tienen nombres significativos. 4. Tipo de datos y Contenido de cada parámetro recibido . Si se inicializa una variable a un número especial distinto de 0. String. 8. se han de seguir los siguientes lineamientos: 1.Empty o Null. -1. asegurándose de que la puntuación es utilizada correctamente.COMENTARIOS Comentarios correctos y significativos hacen al código más mantenible. se deberá documentar la razón por la que se ha escogido dicho valor. 7. se debe documentar correctamente con suficientes comentarios. 3. Si todas las variables. 6. 2. sin embargo.

No guarde objetos de gran tamaño en la sesión. MANEJO DE EXCEPCIONES 1. el método y nombre de la clase.Current. utilice la instrucción throw sin especificar la excepción original. Si se oculta una excepción. ASP.HttpCOntext. etc. a partir de estos comentarios. Utilice variables de sesión sólo dentro de clases y proporcione métodos para acceder al valor almacenado en estas variables. Esto le ayudará a cambiar la interfaz de usuario de su aplicación fácilmente en el futuro. usted debe registrar la excepción en un log y continuar. si usted desea personalizar la interfaz de usuario. No utilice las variables de sesión a través del código. Nunca especificar el nombre de fuente y tamaño en ninguna de las páginas. 2. 3. Nunca “capturar una excepción y no hacer nada”. . Utilice clases de estilo. pero se debe logear la excepción actual con todos los detalles posibles sobre el error. Una clase puede tener acceso a las variables de sesión mediante System. la llamada original conserva la pila. Trate de evitar las excepciones comprobando todas las condiciones de error mediante programación. En el peor de los casos.Session. Muchos desarrolladores utilizan este método para ignorar errores no significativos. Así. Siempre capturar una excepcion especifica. incluyendo el momento en que ocurrió.• El propósito de la información retornada • Esto es particularmente útil para generar documentación de forma automática. Esto puede consumir gran cantidad de memoria del servidor en función del número de usuarios. no genéricas.Web. mostrar un mensaje amigable al usuario. 2. Siempre use una hoja de estilo para controlar la apariencia de las páginas. nunca se sabrá si la excepción sucedido. sólo es cuestión de desarrollar una hoja de estilos nueva.NET 1. Cuando vuelva a lanzar una excepción. En casos de excepción. De esta manera.

Esto está estrictamente prohibido. siempre debe utilizar controladores de excepciones. Siempre debe comprobar si hay errores de forma explícita en lugar de esperar que se produzcan excepciones. . Por ejemplo. Estos sistemas están sujetos a fallos en cualquier momento y la comprobación de errores no suele ser fiable. 5. Utilícelo sólo si hay una posibilidad de que una excepción específica se puede producir y no se puede evitar por cualquier otro medio. o de otra clase base propia • El nombre de la clase culminarlo con “Exception • Considerar proveer propiedades adicionales. A su vez. si desea insertar un registro en la base de datos. 6. 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. En esos casos. Algunos desarrolladores tratan de insertar un registro sin comprobar si ya existe. deberán ser colocados bajo la carpeta ProjectoName\Tests en el proyecto Customers. como de red. debe tratar de recuperarse del error. Cada archivo correspondiente a un test unitario. Escriba sus propias clases excepción si se requiere en la aplicación: • Heredar de Exception. TESTING UNITARIO Cada una de las operaciones desarrolladas deberá contar con tantos test unitarios como escenarios de prueba se deseen. deberá ser nomenclado respetando el siguiente patrón: “UnitTest” + [Nombre Clase que se testea] Cada nombre de método cumplirá con la forma “Test_” + [Nombre Método] + [Descripción de Entrada] Ejemplos: Los test unitarios correspondientes al módulo de “Customers”. y categorizado (en la forma de proyecto) en función del módulo al que corresponda. dentro de cada proyecto de test. Creación de test unitarios Cada test unitario deberá ser creado bajo la carpeta ProjectoName\Tests. etc. Si es necesario. dispositivos hardware.4. No escriba try-catch en todos sus métodos. si se comunica con sistemas externos. Por otro lado. Esto le ayudará a encontrar el código que genera la excepción y se puede dar mensaje de error específico al usuario. No escriba bloques try-catch muy grandes. escribir por separado try-catch para cada tarea de realizar e incluya sólo la parte específica del código dentro del try-catch.

Ejecutar absolutamente todos los test desarrollados. Esto simplificará la organización de los tests y facilitará la tarea de seleccionar la ubicación de cada uno de ellos. 4. Create Test List) que incluya todos los test asociados al módulo. Cada test unitario debe ser independiente. correspondiente al módulo “Customers” se seguirán los siguientes pasos: Se creará la clase “UnitTestCustomerServices” y se ubicará en Projecto\Tests\Customers. 3. incluyendo casos de borde. Evitar crear dependencias entre tests que impliquen que deban ser ejecutados en un orden particular. Evitar crear tests que involucren información específica del equipo. tipo de arquitectura de procesador. se creará el método de Test_ValidateCustomer_InvalidNumbers”. cuando se realojen cambios. como por ejemplo versiones de software. Prácticas recomendadas 1. Dentro de la clase antedicha. Se agregará código para verificar que la validación de clientes opera de acuerdo a lo esperado cuando recibe ingresos no válidos. antes de hacer check-in y previo al empaquetado de una nueva versión. rutas de acceso. . Alcance de la validación Cada método de validación que sea creado debe contemplar los casos que se tracen como posibles escenarios de ejecución válidos. 2. 5.Si se desea verificar el método “ValidateCustomer” de una clase de nombre “CustomerServices”. Crear una clase de test para cada una de las clases que se desean verificar. Esto permitirá que los mismos sean administrados de forma conjunta. Asegurarse de que los tests cubren todas las operaciones definidas en cada servicio. Organización de Tests Para cada módulo de la solución se deberá crear una “Test List” (Menú Test.