Le nombre moyen de bogues par locus est-il le même pour différents langages de programmation? [fermé]

On m'a dit que le nombre moyen de bogues / défauts par ligne de code est "constant" pour différents langages de programmation. 10 KLOC de Ruby auraient le même nombre de bugs que 10 KLOC de c ++. L'argument est généralement utilisé pour promouvoir l'utilisation de langages d'expression (pensez à python / ruby ​​plutôt qu'à c ++ / assembly) car le nombre de lignes décrivant la même fonctionnalité serait plus petit.

Quelqu'un sait-il d'où provient cette revendication? Est-ce que les langages de haut niveau entraînent moins de bugs?

Contrairement à l’intuition, le nombre d’erreurs sur 1 000 lignes semble être relativement constant, indépendamment du langage utilisé. Steve McConnell , auteur de Code Complete et Estimation du logiciel: Démystifier le noir, décrit ce domaine de manière assez détaillée.

Je n'ai pas facilement mes copies sous la main - elles sont assises au travail sur mon étagère - mais un rapide Google a trouvé une citation pertinente:

Moyenne de l'industrie: "environ 15 à 50 erreurs pour 1000 lignes de code livré".
(Steve) ajoute que ceci est généralement représentatif d'un code qui s'appuie sur un certain niveau de programmation structurée, mais qui inclut probablement un mélange de techniques de codage.

Cité de Code Complete , trouvé ici: http://mayerdan.com/ruby/2012/11/11/bugs-per-line-of-code-ratio/

Si la mémoire est correctement utilisée, Steve entame une discussion approfondie à ce sujet, montrant que les chiffres sont constants dans toutes les langues (C, C ++, Java, Assembly, etc.) et malgré les difficultés (telles que la définition de "ligne de code").

Plus important encore, il a beaucoup de citations pour ses sources - il n'offre pas d'opinions non fondées, mais a les références pour les sauvegarder.

Cela semble résumer à ceci: le nombre moyen de défauts par kloc semble être davantage une propriété du fait que les développeurs sont des êtres humains faillibles que des avantages ou des inconvénients particuliers d'un langage ou d'une plate-forme particulière.

(De plus, si vous ne possédez pas encore Code Complete, achetez-vous-en un exemplaire et lisez-le attentivement. Cet investissement en vaut vraiment la peine.)

Mise à jour : Un autre facteur est en jeu dans certaines des réponses: les statistiques à grande échelle sont utiles pour établir des prévisions générales, mais non des prédictions spécifiques. Considérez que les tables de mortalité de la population peuvent prédire le nombre de personnes qui seront tuées dans des accidents de la route cette année, mais ne peuvent pas vous dire quelles personnes vont mourir. De même, les statistiques du secteur qui indiquent un nombre relativement constant de défauts par kloc ne permettent pas de prédire la performance (ou la médiocre) performance d’un développeur particulier ni de ce qui se passera dans un projet donné.

La réclamation est - au mieux - naïve.

Le SLOC n'est pas une mesure fiable pour quoi que ce soit d'utile, sauf peut-être en comparant la taille de deux projets ou plus. De plus, il existe deux types distincts de SLOC, le LOC physique et le LOC logique, et ceux-ci peuvent être très différents. Prenons cet exemple, tiré de Wikipedia :

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

Nous avons ici une LOC physique, mais deux logiques ( foret printfdéclarations). Mais nous pourrions bien sûr écrire l'exemple sous la forme:

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

Ce qui nous donnerait deux LOCs physique et deux logiques. Je pense qu'il est clair que toute mesure de "bogue par emplacement" qui dépendrait de LOCs physiques serait entachée par le style de programmation; notre mesure serait donc en grande partie inutile.

Si, par contre, nous utilisions des LOC logiques, notre mesure dépendrait fortement des idiosyncrasies syntaxiques du langage. Bien que la métrique résultante puisse être un peu utile lors de la comparaison de projets écrits dans la même langue, elle serait plutôt inutile pour des projets écrits dans des langues différentes.

L’une des sources possibles de cette réclamation est la faille et les faussetés :

Nous pouvons en conclure que le choix du langage de programmation est au mieux faiblement lié à la fiabilité.

Plus tard, l'article mentionne des densités de défauts similaires pour C et C ++:

Dans une étude récente comparant deux systèmes similaires de taille similaire (environ 50 000 lignes chacune), un en C et un en C ++ conçu par un objet, les densités de défauts résultantes étaient à peu près identiques à 2,4 et 2,9 par 1000 lignes respectivement.

Ceci, cependant, ne signifie pas que "bug par LOC" est constant dans tous les langages de programmation, ou qu'il serait significatif s'il l'était.

Cette observation est très ancienne et provient d'une source très vénérable, à savoir Fred Brooks dans son livre "Le Mois des hommes mythiques". Il était cadre supérieur chez IBM et a géré de nombreux projets de programmation, notamment le système d’exploitation OS / 360. En fait, il a signalé que le nombre de bogues dans un programme n’est pas proportionnel à la longueur du code, mais quadratique ! Selon ses recherches, le nombre de bugs était proportionnel à la longueur du programme et à la puissance de 1,5. En d'autres termes, un programme dix fois plus long contient 30 fois plus de bogues. Et il a signalé que cela s’appliquait à tous les langages de programmation et à tous les niveaux de langages de programmation.

Je ne trouve pas que Bugs par LOC soit constant pour une langue donnée. Les bogues par LOC semblent être une métrique que certains gestionnaires utilisent pour déterminer la qualité des développeurs en ce qui concerne le temps de révision.

Maintenant en dehors de cela, certaines langues sont plus sujettes aux erreurs ou aux défauts que d'autres. Habituellement, mais pas toujours, il s'agit d'un langage de niveau inférieur à celui d'un niveau supérieur. Par exemple, coder en C ou en C # (ou Java.), C’est généralement parce que la réalité et le cœur de la réponse que vous recherchez dépendent de la qualité du développeur et des pratiques de codage en place. J'ai vu de très bons développeurs C avec une qualité de code bien supérieure et un nombre de défauts inférieur à celui des développeurs Java / C # moyens. C'est un élément qui sépare un développeur senior d'un développeur junior. Non pas combien de LOC ils écrivent dans un laps de temps donné, mais la qualité du code écrit indépendamment de la langue, du LOC ou du laps de temps.

La seule réponse que je puisse donner est que plus il y a de défauts, plus il y a de risques de défauts et plus il y a de défauts.

Bugs par ligne de code

Bugs / LOC n'est relatif qu'à un individu. Pour les entreprises qui implémentent des outils de suivi des bogues liés à leur référentiel de code source. Il est possible pour un responsable d’organiser les problèmes par développeur, en fonction des problèmes antérieurs et des modifications de code.

Les bugs sont relatifs à votre travail

Un développeur de logiciel expérimenté, très expérimenté, hautement qualifié, très intelligent et capable d’occuper des emplois indépendants a bien plus de chances d’avoir beaucoup plus de bogues enregistrés dans un système de suivi, qu’un développeur débutant peu expérimenté.

Comment est-ce possible?

Les développeurs expérimentés sont souvent engagés dans des tâches de développement à risque plus élevé. Refactoring du code et construction de nouveaux systèmes à titre d'exemple. Les développeurs juniors sont souvent chargés de résoudre des problèmes connus qui ne valent pas la peine d'un développeur senior.

Par conséquent, par attribution de tâche, un junior n'introduit pas de bogues, mais le corrige, et le développeur principal est autorisé à les introduire, car l'avantage de ce qu'il tente d'archiver est plus important que les problèmes mineurs soulevés pour les résoudre. les tâches.

La syntaxe linguistique est importante

L'argument selon lequel un langage introduit moins de bogues, car il peut en faire plus en moins de lignes de code est un mythe complet. Les langages très structurés tels que C ++ / C # / Java obligent le développeur à exprimer clairement par écrit ce que devrait être l’instruction désirée, alors que des langages comme Python / PHP sont très non structurés. Ces langages permettent des expressions écrites qui non seulement déroutent le développeur, mais également l’analyseur de langage.

Le compilateur réduit les bugs

Combien de bogues dans Python / PHP ont été intégrés aux serveurs de production, car il n'y avait pas de compilateur pour avertir le développeur que quelque chose était incorrect. Lorsque vous mesurez les bogues par LOC, cela est-il avant ou après qu'un compilateur ait traité le code source?

Mise à jour 2019:

Les compilateurs ne font aucune différence sur la nature ou le nombre de bugs. Les bogues sont purement relatifs à la personne qui a écrit le code source, et les bogues eux-mêmes peuvent être de nature très subjective.

FWIW, dans mon expérience

1. Il existe deux types de bogues: a) le programme ne répond pas aux attentes et b) le programme ne peut répondre à aucune attente raisonnable, car il se bloque / se bloque / ne se compile pas.

2. Indépendamment de la langue, les bogues de type (b) sont dus à la redondance dans la structure de données / classes, où modifier quelque chose dans une partie de la structure de données place la structure dans un état incohérent / cassé jusqu'à ce qu'un ou plusieurs changements correspondants soient apportés dans d'autres parties. . La redondance du code source y contribue, dans laquelle une modification d'une ligne de code rend le code incorrect jusqu'à ce qu'un ou plusieurs changements soient apportés dans d'autres parties. Bien entendu, ces deux types de redondance sont étroitement liés et, les programmeurs n'étant pas des super-personnes, ils sont distraits, oublient des choses et commettent des erreurs, créant ainsi des bugs.

Ces choses (encore une fois, selon mon expérience) ne sont pas vraiment fonction de la langue, mais de la compétence / maturité du programmeur. Les programmes qui sont beaucoup moins sujets aux bogues ont aussi tendance à être beaucoup plus petits, en termes de LOC, pour un ensemble de fonctionnalités donné.

J'ai vu des systèmes où certaines personnes écrivent des programmes, tandis que d'autres écrivent des répertoires, et les premiers ont tendance à "fonctionner tout simplement" par rapport aux derniers.

Je m'attendrais à ce qu'un facteur clé des erreurs de codage soit lié à ce que j'appelle le "fossé sémantique" entre un type particulier de définition de solution et le code permettant de le résoudre. différentes, de nombreuses erreurs pourraient être attendues. Le paradigme de certaines langues correspond étroitement à certains domaines problématiques - les feuilles de calcul conviennent très bien aux calculs d’entreprise courants. Il en résulte que très peu de "code" et le "code" sont très proches du domaine problématique. Le code attendu est à la fois très concis (peu de KLOC) et peu d’erreurs. Inversement, utiliser un assembleur nécessiterait beaucoup de KLOC et risque de générer un nombre considérable d’erreurs.

Au lieu de parler de lignes de code - qui sont en effet une métrique inutile -, j'aimerais aborder cette partie de votre question:

Est-ce que les langages de haut niveau entraînent moins de bugs?

Cela diffère de bugs / LOC, car les langages de niveau supérieur en font plus avec moins de code. L'implémentation de certaines fonctionnalités requises peut prendre 500 lignes d'assemblage LISP par rapport à 15 000 lignes d'assemblage x86.

Ainsi, même si les bogues / LOC sont constants entre toutes les langues, le langage de niveau supérieur produira toujours moins de bogues.