Efqm

Codificación y Buenas Prácticas de Programación



4. Introducción
5. Propósito de los estándares de codificación y las mejores prácticas 3
6. Cómo seguir las normas en todo el equipo 4
7. Convenciones de nomenclatura y normas 4
8. Sangría y espaciado 7
9. Las buenas prácticas de programación 10
10. Arquitectura 15
11. ASP.NET 16
12. Comentarios 16
13. Manejo de excepciones 17Introducción

Cualquiera puede escribir código. Con unos meses de experiencia en programación, puede escribir "aplicaciones de trabajo. Hacer que funcione es fácil, pero hacerlo de la manera correcta requiere más trabajo, que sólo hacer que funcione.

Créalo, la mayoría de los programadores escribir "código de trabajo", pero no "buen código". "Buen código" Escribir es un arte y hay queaprender y practicarlo.

Todo el mundo puede tener diferentes definiciones de "buen código" del término. En mi definición, las siguientes son las características de un buen código.

• Confiable
• Sustentable
• Eficiente

La mayoría de los desarrolladores se inclinan hacia la escritura de código para un mayor rendimiento, lo que compromete la fiabilidad y facilidad de mantenimiento. Peroteniendo en cuenta el retorno de la inversión a largo plazo (Return On Investment), la eficiencia y el rendimiento está por debajo de la fiabilidad y facilidad de mantenimiento. Si el código no es fiable y fácil de mantener, usted (y su compañía) van a pasar mucho tiempo para identificar los problemas, tratando de entender etc. código durante toda la vida de la aplicación.

Propósito de losestándares de codificación y las mejores prácticas

Para desarrollar aplicaciones confiables y mantenibles, debe seguir las normas de codificación y mejores prácticas.

Las convenciones de nomenclatura, normas de codificación y las mejores prácticas descritas en este documento se compilan a partir de nuestra propia experiencia y haciendo referencia a diversos Microsoft y no las directrices deMicrosoft.

Hay varias normas que existe en la industria de programación. Ninguno de ellos es malo o malo y puede seguir cualquiera de ellos. Lo que es más importante es la selección de un enfoque estándar y la garantía de que todo el mundo lo está siguiendo.

Cómo seguir las normas en todo el equipo

Si usted tiene un equipo de diferentes habilidades y gustos, usted va a tener un tiempo difícilconvencer a todos a seguir las mismas normas. El mejor enfoque es tener una reunión del equipo y el desarrollo de su propio documento de estándares. Usted puede usar este documento como una plantilla para preparar su propio documento.

Distribuya una copia de este documento (o en su propio documento estándar de codificación) mucho antes de la reunión de los estándares de codificación. Todos losmiembros deben asistir a la reunión preparado para discutir los pros y los contras de los distintos puntos del documento. Asegúrese de tener un gerente presentes en la reunión para resolver los conflictos.

Discuta todos los puntos del documento. Todo el mundo puede tener una opinión diferente acerca de cada punto, pero al final de la discusión, todos los miembros deben estar de acuerdo a lanorma que se va a seguir. Preparar un documento de estándares nuevo con los cambios apropiados basados ​​en las sugerencias de todos los miembros del equipo. Imprima copias del mismo y publicarlo en todos los puestos de trabajo.

Después de iniciar el desarrollo, debe programar las reuniones de revisión de código para asegurarse de que todo el mundo está siguiendo las reglas. 3 tipos de revisionesde código, se recomienda:

1. Peer review - otro miembro del equipo revisar el código para asegurarse de que el código sigue los estándares de codificación y cumple con los requisitos. Este nivel de revisión puede incluir alguna prueba de la unidad también. Cada archivo en el proyecto debe pasar por este proceso.
2. Revisión Arquitecto - el arquitecto del equipo debe revisar los módulos...