¿El número promedio de errores por loc es el mismo para diferentes lenguajes de programación? [cerrado]

Me han dicho que el número promedio de errores / defectos por línea de código es "constante" para diferentes lenguajes de programación. 10 KLOC de Ruby tendrían el mismo número de errores que 10 KLOC de c ++. El argumento se usa generalmente para promover el uso de lenguajes expresivos (piense en python / ruby ​​sobre c ++ / ensamblador) ya que el número de líneas para describir la misma funcionalidad sería menor.

¿Alguien sabe de dónde viene este reclamo? ¿Los lenguajes de nivel superior conducen a menos errores?

Contrariamente a la intuición, el número de errores por cada 1000 líneas parece ser relativamente constante, independientemente del lenguaje específico involucrado. Steve McConnell , autor de Code Complete y Software Estimation: Demystifying the Black Art repasa esta área con cierto detalle.

No tengo mis copias a mano, están en mi estantería en el trabajo, pero un rápido Google encontró una cita relevante:

Promedio de la industria: "aproximadamente 15 - 50 errores por 1000 líneas de código entregado".
(Steve) dice además que esto generalmente es representativo del código que tiene algún nivel de programación estructurada, pero que probablemente incluye una combinación de técnicas de codificación.

Citado de Code Complete , que se encuentra aquí: http://mayerdan.com/ruby/2012/11/11/bugs-per-line-of-code-ratio/

Si la memoria funciona correctamente, Steve entra en una discusión exhaustiva de esto, mostrando que las cifras son constantes en todos los lenguajes (C, C ++, Java, Assembly, etc.) y a pesar de las dificultades (como definir qué significa "línea de código").

Lo más importante es que tiene muchas citas para sus fuentes: no está ofreciendo opiniones sin fundamento, pero tiene las referencias para respaldarlas.

Parece reducirse a esto: el número promedio de defectos por kloc parece ser más una propiedad del hecho de que los desarrolladores son humanos falibles que las ventajas o desventajas particulares de un lenguaje o plataforma en particular.

(Aparte: si aún no tiene Code Complete, compre una copia y léala a fondo, vale la pena la inversión).

Actualización : hay otro factor en juego con algunas de las respuestas aquí: las estadísticas a gran escala son útiles para hacer predicciones generales pero no específicas. Tenga en cuenta que las tablas de mortalidad de la población pueden predecir cuántas personas morirán en accidentes de tráfico este año, pero no pueden decirle qué personas morirán. Del mismo modo, las estadísticas de la industria que muestran un número relativamente constante de defectos por kloc no se pueden utilizar para predecir qué tan bien, o qué tan mal, se desempeñará un desarrollador en particular o qué sucederá en un proyecto determinado.

La afirmación es, en el mejor de los casos, ingenua.

SLOC no es exactamente una métrica confiable para nada útil, excepto quizás comparar el tamaño de dos o más proyectos. Además, hay dos tipos distintos de SLOC, LOC físico y LOC lógico, y estos pueden diferir significativamente. Considere este ejemplo, de Wikipedia :

for (i = 0; i < 100; i += 1) printf("hello"); 

Aquí tenemos un LOC físico, pero dos lógicos ( fory printfdeclaraciones). Pero, por supuesto, podríamos escribir el ejemplo como:

for (i = 0; i < 100; i += 1) 
  printf("hello"); 

Lo que nos daría dos LOC físicos y dos lógicos. Creo que está claro que cualquier medición de "error por loc" que dependería de los LOC físicos estaría contaminada por el estilo de programación, por lo que nuestra medición sería en gran medida inútil.

Si, por otro lado, utilizamos LOC lógicos, nuestra medición dependería en gran medida de las idiosincrasias sintácticas del lenguaje. Aunque la métrica resultante podría ser un poco útil al comparar proyectos escritos en el mismo idioma, sería bastante inútil para proyectos escritos en diferentes idiomas.

Una posible fuente para el reclamo son las fallas de software de Les Hatton, locuras y falacias :

Podemos concluir que la elección del lenguaje de programación está, en el mejor de los casos, débilmente relacionada con la confiabilidad.

Más adelante, el artículo menciona densidades de defectos similares para C y C ++:

En un estudio reciente que comparó dos sistemas similares de tamaño similar (alrededor de 50,000 líneas cada uno), uno en C y otro en C ++ diseñado por objetos, se demostró que las densidades de defectos resultantes eran aproximadamente iguales en 2.4 y 2.9 por 1000 líneas respectivamente.

Sin embargo, esto no significa que el "error por LOC" sea constante en todos los lenguajes de programación, o que sería significativo si lo fuera.

Esta observación es muy antigua y proviene de una fuente muy venerable, a saber, Fred Brooks en su libro "The Mythical Man Month". Fue gerente superior en IBM y administró muchos proyectos de programación, incluido el sistema operativo de millones de líneas OS / 360. De hecho, informó que la cantidad de errores en un programa no es proporcional a la longitud del código, ¡sino cuadrática ! Según su investigación, el número de errores fue proporcional a la duración del programa a la potencia 1.5. En otras palabras, un programa que es diez veces más largo tiene 30 veces más errores. E informó que esto se aplicaba a todos los lenguajes de programación y niveles de lenguajes de programación.

No creo que los errores por LOC sean constantes para un idioma determinado. Los errores por LOC parecen una métrica que algunos gerentes usan para determinar la calidad de los desarrolladores cuando se trata del tiempo de revisión.

Ahora, aparte de eso, algunos idiomas son más propensos a errores o defectos que otros. Por lo general, pero no siempre, este es un lenguaje de nivel inferior que uno más alto. Por ejemplo, la codificación en C versus C # (o Java). Digo generalmente porque la realidad y el quid de la respuesta que busca se reduce a la calidad del desarrollador y las prácticas de codificación vigentes. He visto muy buenos desarrolladores de C con una calidad de código mucho más alta y recuentos de defectos más bajos que los desarrolladores promedio de Java / C #. Este es un elemento que separa a un desarrollador senior de uno junior. No cuántos LOC escriben en un período de tiempo determinado, sino la calidad del código que escriben independientemente del idioma, LOC o período de tiempo.

La única respuesta que puedo dar que podría relacionarse es que cuanto más LOC hay, más probable es que haya un defecto y más defectos existen.

Errores por línea de código

Bugs / LOC solo es relativo a un individuo. Para las empresas que implementan herramientas de seguimiento de errores que se vinculan con su repositorio de código fuente. Es posible que un gerente organice los problemas por desarrollador, ordenados por problemas pasados ​​y cambios de código.

Los errores son relativos a su trabajo

Un desarrollador de software senior, que tiene mucha experiencia, mucha habilidad, es muy inteligente y puede realizar trabajos independientes, es mucho más probable que tenga muchos más errores registrados en un sistema de seguimiento, que un desarrollador junior con poca experiencia.

¿Cómo es eso posible?

Los desarrolladores senior a menudo se dedican a tareas de desarrollo de mayor riesgo. Refactorización de código y construcción de nuevos sistemas como ejemplo. Los desarrolladores junior a menudo se asignan para solucionar problemas conocidos que no valen la pena el tiempo de un desarrollador senior.

Por lo tanto, mediante la asignación de tareas, un junior no está introduciendo errores, sino reparándolos, y un desarrollador senior tiene el riesgo de presentarlos, porque el beneficio de lo que están tratando de archivar es más importante que los problemas menores que se plantean al completarlos Tareas.

La sintaxis del idioma es importante

El argumento de que un lenguaje introduce menos errores, porque puede lograr más en menos líneas de código es un mito completo. Lenguajes altamente estructurados como C ++ / C # / Java obligan al desarrollador a expresar claramente por escrito cuál debería ser la instrucción deseada, ya que los lenguajes como Python / PHP son muy desestructurados. Esos lenguajes permiten expresiones escritas que no solo confundirán a un desarrollador, sino también al analizador de lenguaje.

El compilador reduce errores

¿Cuántos errores en Python / PHP han llegado a los servidores de producción, porque no había compilador para advertir al desarrollador que algo era incorrecto? Cuando mide errores por LOC, ¿es eso antes o después de que un compilador haya procesado el código fuente?

Actualización 2019:

Los compiladores no hacen ninguna diferencia en la naturaleza o el número de errores. Los errores son puramente relativos a la persona que escribió el código fuente, y los errores en sí mismos pueden ser de naturaleza muy subjetiva.

FWIW, en mi experiencia

1. Hay dos tipos de errores: a) donde el programa no cumple con las expectativas, yb) donde el programa no puede cumplir con ninguna expectativa razonable, porque se bloquea / se bloquea / no se compila.

2. Independientemente del idioma, los errores de tipo (b) son causados ​​por la redundancia en la estructura de datos / clases, donde cambiar algo en una parte de la estructura de datos coloca la estructura en un estado inconsistente / roto hasta que se realicen uno o más cambios correspondientes en otras partes . Contribuir a esto es la redundancia del código fuente, donde una edición en una línea de código hace que el código sea incorrecto hasta que se realicen uno o más cambios en otras partes. Estos dos tipos de redundancia están estrechamente relacionados, por supuesto, y dado que los programadores no son superpersonas, se distraen, olvidan cosas y cometen errores, lo que provoca errores.

Estas cosas (de nuevo, en mi experiencia) no son realmente una función del lenguaje, sino de la habilidad / madurez del programador. Los programas que son mucho menos propensos a errores también tienden a ser mucho más pequeños, en términos de LOC, para un conjunto dado de funcionalidades.

He visto sistemas en los que algunas personas escriben programas, mientras que otras escriben directorios, y los primeros tienden a "simplemente funcionar" en comparación con los segundos.

Esperaría que un factor clave en los errores de codificación se relacione con lo que yo llamo la "brecha semántica" entre un tipo particular de definición de solución y el código para resolverlo; donde estos son errores de reformulación cercanos, sería más evidente, donde el código es muy diferente, se pueden esperar muchos errores. El paradigma de ciertos idiomas coincide estrechamente con ciertos dominios problemáticos: las hojas de cálculo son muy apropiadas para los cálculos comerciales cotidianos, lo que resulta en que muy poco "código" y el "código" estén muy cerca del dominio del problema. El código esperado es muy conciso (poco KLOC) y pocos errores. Por el contrario, usar ensamblador requeriría muchos KLOC y es probable que produzca una inmensa cantidad de errores.

En lugar de hablar sobre líneas de código, que de hecho son una métrica inútil, me gustaría abordar esta parte de su pregunta:

¿Los lenguajes de nivel superior conducen a menos errores?

Esto es diferente a los errores / LOC, porque los lenguajes de nivel superior hacen más con menos código. La implementación de algunos requisitos de características puede requerir 500 líneas de LISP frente a 15000 líneas de ensamblaje x86.

Por lo tanto, incluso si los errores / LOC son constantes entre todos los idiomas, el lenguaje de nivel superior seguirá produciendo menos errores.