Errores que pueden evitarse con los estándares de codificación [cerrado]

Estoy buscando estadísticas (o estimaciones) que respalden la afirmación de que los estándares de codificación ayudan a reducir errores. Los números duros serían buenos, aunque no he tenido mucho interés en encontrarlos. Incluso he visto el seguimiento de errores para varios proyectos de código abierto, pero no he tenido mucho éxito en encontrar lo que necesito. ¿Alguien por ahí sabe de algún lugar donde pueda encontrar esto? ¿O alguno de ustedes contribuye a proyectos de código abierto que hayan tenido errores que podrían haberse evitado con mejores estándares de codificación?

Los estándares de codificación por sí solos no reducen los errores. Los estándares de codificación como parte de un proceso de desarrollo de software sólido reducen los errores.

Aquí hay dos documentos que estudian el impacto estadístico del proceso de ingeniería de software de sonido en la reducción de defectos que puede utilizar como punto de partida:

• Lista de los 10 principales para la reducción de defectos de software , que analiza las mejoras en la ingeniería de software basada empíricamente desde 1987
• Un análisis crítico del proceso de datos de PSP , que estudia las estadísticas recopiladas del proceso de software personal y el impacto de PSP en las causas comunes de errores de software

Codificación de "estándares" ... Hay muchas áreas de desarrollo que pueden estandarizarse. ¿Estamos hablando de convenciones de codificación, como estándares de nomenclatura, etc.? ¿O estamos hablando de algo más profundo, como TDD / BDD, CI, etc.?

Puedo decirle que la adhesión a una metodología de "prueba primero", con CI que impone pruebas de aprobación y una buena cobertura de código, reduce la cantidad de errores encontrados por el cliente. Las pruebas automatizadas, tanto por parte del desarrollador como del control de calidad, también son una forma relativamente "barata" de encontrar errores porque generalmente tienen tiempos de respuesta muy cortos. Puedes saber que no escribiste lo que creías que escribiste al ejecutar aproximadamente 45 segundos de pruebas unitarias. Un par de horas de pruebas de integración encontrarán lugares donde conectar las cosas no salieron según lo planeado, y las pruebas de interfaz de usuario de extremo a extremo y automatizadas pueden detectar rápidamente fallas funcionales en el software a niveles muy altos.

También evitan la regresión. Encontraste un error. Escribe una prueba que demostrará que el comportamiento ya no ocurre, codifica hasta que la prueba pase, y ahora tiene una prueba que de ahora en adelante garantizará que el error nunca vuelva a ser un problema. Esto es, en mi experiencia, una fuente importante de nuevos errores; arreglar una cosa rompe otra cosa, y la prueba del desarrollador de la corrección puede no cubrir esa otra situación que ahora está rota. Romper cosas que solían funcionar es una ENORME bandera roja para tus clientes.

Por último, esta estructura de prueba automatizada que usted construye como parte de esta metodología le dará muy fácilmente un entorno en el que puede lanzar una nueva compilación del software, literalmente, en cualquier momento. "Oye, ese error que acabas de arreglar ha estado causando verdaderos dolores de cabeza; ¿cuándo lo tendrás listo en una nueva versión?" haga clic en "Oh, en unos 5 minutos cuando el servidor de compilación termine de publicarlo en la página de descarga".

En cuanto a las convenciones básicas de codificación, como la estandarización de nombres de variables, etc., he encontrado que la mayoría de eso es menos útil y más irritante. Esos son los tipos de estándares que son "maravillosos, porque hay muchos para elegir". Lo que percibes como la diferencia entre un identificador PascalCased y un camelCased puede no ser lo que otra persona piensa. Guiones bajos destacados, límites de longitud de nombre (o requisitos que los nombres de método / campo cuentan una historia); Además de las convenciones impuestas por el compilador o que se ven comúnmente en el código de la biblioteca específica del idioma, el IDE moderno puede decirle todo lo que necesita saber sobre una variable o función, incluso si debe o no intentar usarlo en un determinado circunstancia. Además, ejecutar una verificación de convención de código a menudo devolverá problemas con código que no puede o no puede hacer ' No desea cambiar, como una biblioteca de terceros que utiliza un conjunto diferente de estándares, o un código de interoperabilidad que puede cumplir con los estándares de nombres de Win API en lugar de los estándares de su idioma nativo. Terminas agregando cruft a tu código para decirle a tu herramienta que ignore el cruft en tu código.

Cada vulnerabilidad de inyección SQL es un defecto que podría haberse evitado con un estándar de codificación. Las estadísticas sobre vulnerabilidades de inyección SQL están, AFAIK, disponibles.

Toda vulnerabilidad de desbordamiento del búfer podría haberse evitado con un estándar de codificación. Las estadísticas sobre esos probablemente también estén disponibles.