Le nombre moyen de bogues par emplacement est-il le même pour différents langages de programmation?
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 aurait le même nombre de bogues que 10 KLOC de c ++. L'argument est généralement utilisé pour promouvoir l'utilisation de langages expressifs (pensez python/Ruby sur c ++/Assembly) depuis le le nombre de lignes pour décrire la même fonctionnalité serait plus petit.
Quelqu'un sait-il d'où vient cette affirmation? Les langages de niveau supérieur entraînent-ils moins de bogues?
Contrairement à l'intuition, le nombre d'erreurs pour 1000 lignes de ne semble être relativement constant, indépendamment du langage spécifique impliqué. Steve McConnell, auteur de Code Complete et Estimation logicielle: démystifier l'art noir passe en revue cette zone en détail.
Je n'ai pas mes exemplaires à portée de main - ils sont assis sur ma bibliothèque au travail - mais un rapide Google a trouvé une citation pertinente:
Moyenne de l'industrie: "environ 15 à 50 erreurs pour 1 000 lignes de code fournies".
(Steve) dit en outre que cela est généralement représentatif du code qui a un certain niveau de programmation structurée derrière, mais comprend probablement un mélange de techniques de codage.
Cité de Code complet , trouvé ici: http://mayerdan.com/Ruby/2012/11/11/bugs-per- rapport ligne de code /
Si la mémoire est bonne, Steve entame une discussion approfondie à ce sujet, montrant que les chiffres sont constants à travers les langages (C, C++, Java, Assembly, etc.) et malgré les difficultés (telles que la définition de ce que signifie "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 soutenir.
Cela semble se 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 humains faillibles que des avantages ou des inconvénients particuliers d'un langage ou d'une plate-forme particulière.
(À part: si vous n'avez pas encore le code complet, achetez-vous une copie et lisez-la attentivement - cela vaut bien l'investissement.)
Mise à jour : Il y a un autre facteur en jeu avec certaines des réponses ici - les statistiques à grande échelle sont utiles pour faire des prédictions générales mais pas spécifiques. Considérez, les tables de mortalité de la population peuvent prédire combien de personnes seront tuées dans des accidents de la circulation cette année, mais ne peuvent pas vous dire quelles personnes vont mourir. De même, les statistiques de l'industrie qui montrent un nombre relativement constant de défauts par kloc ne peuvent pas être utilisées pour prédire dans quelle mesure - ou à quel point - un développeur particulier fonctionnera ou ce qui se passera sur un projet donné.
L'affirmation est - au mieux - naïve.
SLOC n'est pas exactement 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 peuvent différer de manière significative. Considérez cet exemple, de Wikipedia :
for (i = 0; i < 100; i += 1) printf("hello");
Nous avons ici un LOC physique, mais deux logiques (instructions for et printf). Mais nous pourrions bien sûr écrire l'exemple comme suit:
for (i = 0; i < 100; i += 1)
printf("hello");
Ce qui nous donnerait deux LOC physiques et deux LOC logiques. Je pense qu'il est clair que toute mesure "bug par loc" qui dépendrait des LOC physiques serait entachée par le style de programmation, donc notre mesure serait largement inutile.
Si, d'autre part, nous options pour 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 assez inutile pour des projets écrits dans différentes langues.
Une source possible pour la réclamation est Les Hatton's Software pannes-follies and fallacies :
Nous pouvons 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 50000 lignes chacun), un en C et un en C++ conçu par objet, les densités de défauts résultantes se sont avérées être les mêmes à 2,4 et 2,9 pour 1000 lignes respectivement.
Cependant, cela ne signifie pas que le "bogue 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 de l'homme mythique". Il était un cadre supérieur chez IBM et a géré de nombreux projets de programmation, y compris le système d'exploitation des millions de lignes 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 durée du programme à la puissance 1,5. En d'autres termes, un programme dix fois plus long comporte 30 fois plus de bogues. Et il a indiqué que cela concernait tous les langages de programmation et les niveaux de langages de programmation.
Je ne trouve pas que les bugs par LOC soient constants du tout pour une langue donnée. Les bogues par LOC semblent être une mesure que certains gestionnaires utilisent pour déterminer la qualité des développeurs en ce qui concerne le temps de révision.
En dehors de cela, certaines langues sont plus sujettes aux erreurs ou aux défauts que d'autres. Habituellement, mais pas toujours, c'est une langue de niveau inférieur à une langue supérieure. Par exemple, le codage en C par rapport à C # (ou Java.) Je dis généralement parce que la réalité de celui-ci et le nœud de la réponse que vous recherchez se résument à la qualité du développeur et aux pratiques de codage en place. J'ai vu de très bons développeurs C avec une qualité de code beaucoup plus élevée 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. Pas combien de LOC ils écrivent dans un laps de temps donné, mais la qualité du code de l'écriture indépendamment de la langue, du LOC ou du laps de temps.
La seule chose que je puisse donner qui pourrait être liée est que plus il y a de LOC, plus il y a de chances qu'il y ait un défaut et plus il y a de défauts.
Bogues par ligne de code
Bugs/LOC est uniquement relatif à 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 gestionnaire d'organiser les problèmes par développeur, triés par problèmes passés et modifications de code.
Les bogues sont liés à votre travail
Un développeur de logiciels senior, très expérimenté, hautement qualifié, très intelligent et capable de prendre des emplois indépendants est beaucoup plus susceptible d'avoir beaucoup plus de bogues enregistrés dans un système de suivi, puis un développeur junior avec peu d'expérience.
Comment est-ce possible?
Les développeurs seniors sont souvent engagés dans des tâches de développement à plus haut risque. Refactorisation de code et construction de nouveaux systèmes à titre d'exemple. Les développeurs juniors sont souvent chargés de résoudre les problèmes connus qui ne valent pas le temps d'un développeur senior.
Par conséquent, en attribuant une tâche, un junior n'introduit pas de bugs mais les corrige, et un développeur senior a le risque de les introduire, car le bénéfice de ce qu'il essaie d'archiver est plus important que les problèmes mineurs qui se posent en les corrigeant. Tâches.
La syntaxe des langues 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 hautement structurés comme C++/C #/Java forcent le développeur à exprimer clairement par écrit ce que devrait être l'instruction souhaitée, alors que les langages comme Python/PHP sont très peu structurés. Ces langages permettent des expressions écrites qui non seulement perturberont un développeur, mais aussi l'analyseur de langage.
Le compilateur réduit les bogues
Combien de bogues en Python/PHP ont été détectés sur les serveurs de production, car il n'y avait pas de compilateur pour avertir le développeur que quelque chose était incorrect. Lorsque vous mesurez des bogues par LOC, est-ce avant ou après qu'un compilateur a traité le code source?
Mise à jour 2019:
Les compilateurs ne font aucune différence sur la nature ou le nombre de bogues. 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, selon mon expérience
Il existe deux types de bogues: a) lorsque le programme ne répond pas aux attentes et b) lorsque le programme ne peut répondre à aucune attente raisonnable, car il se bloque/se bloque/ne se compile pas.
Quel que soit le langage, les bogues de type (b) sont causés par la redondance de la structure des données/classes, où le changement de quelque chose dans une partie de la structure de données met la structure dans un état incohérent/cassé jusqu'à ce qu'une ou plusieurs modifications correspondantes soient apportées dans d'autres parties . La redondance du code source contribue à cela, où une modification sur une ligne de code rend le code incorrect jusqu'à ce qu'une ou plusieurs modifications soient apportées dans d'autres parties. Ces deux types de redondance sont étroitement liés, bien sûr, et comme les programmeurs ne sont pas des super-personnes, ils sont distraits, oublient des choses et font des erreurs, ce qui crée des bogues.
Ces choses (encore une fois, selon mon expérience) ne sont pas vraiment une fonction du langage, mais de la compétence/maturité du programmeur. Les programmes beaucoup moins sujets aux bogues ont également 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" par rapport aux seconds.
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 pour le résoudre - où ce sont des erreurs de reformulation proches seraient plus apparentes, où le code est très différent, de nombreuses erreurs peuvent être attendues. Le paradigme de certaines langues correspond étroitement à certains domaines problématiques - les feuilles de calcul sont très appropriées pour les calculs commerciaux quotidiens, ce qui fait que très peu de "code" et que 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. À l'inverse, utiliser l'assembleur nécessiterait de nombreux KLOC et est susceptible de produire un nombre immense d'erreurs.
Au lieu de parler de lignes de code - qui sont en effet une métrique inutile - je voudrais répondre à cette partie de votre question:
Les langages de niveau supérieur entraînent-ils moins de bogues?
C'est différent de bugs/LOC, car les langages de niveau supérieur font plus avec moins de code. L'implémentation de certaines exigences de fonctionnalité peut prendre 500 lignes de LISP contre 15000 lignes d'assemblage x86.
Ainsi, même si bugs/LOC est constant entre toutes les langues, la langue de niveau supérieur produira toujours moins de bogues.