Quel est l'effet du langage de programmation sur la qualité du logiciel ?
Une étude tente de clarifier la situation
Le 2014-11-06 15:32:01, par Hinault Romaric, Responsable .NET
Si l’on posait la question à savoir « quel est le meilleur langage de programmation ? », ou « pourquoi avez-vous optez pour ce langage de programmation ? », on se retrouvera probablement avec un long débat houleux.
D’aucuns affirmeront que le langage qu’ils utilisent permet d’obtenir un code de meilleure qualité, plus lisible et facilement maintenable. D’autres que leur langage offre plus de sécurité, permet d’avoir moins de bugs, etc. Bref, chacun sortira des arguments pour défendre avec conviction le langage de programmation qu’il utilise. Au final, on se rendra probablement compte que le débat est beaucoup plus religieux que scientifique.
Pourtant, les différences au niveau de la qualité de code entre les langages de programmation sont assez petites. C’est la conclusion d’une étude réalisée par des informaticiens de l’université de Californie, qui sera présentée ce mois lors d’un colloque à Hong Kong sur le génie logiciel.
L’étude a été faite en utilisant un ensemble très vaste de données disponibles sur GitHub. Les chercheurs ont analysé 729 projets, environ 80 millions de lignes de code de 29 000 auteurs et 1,7 million de commits, dans 17 langages de programmation.
Au vu de la grande taille de l’échantillon, les chercheurs ont utilisé une approche de « méthodes mixtes », combinant un modèle de régression multiple avec l’analyse de texte, le regroupement et la visualisation.
Ils ont constaté, par exemple, que le typage fort est légèrement meilleur que le typage faible. Que pour les langages fonctionnels, le typage statique était légèrement mieux que le typage dynamique.
En analysant les erreurs génériques en programmation, ceux-ci ont constaté une domination des fautes de frappe, des erreurs de type, des erreurs de compilation, d’initialisation des données, etc. Ces erreurs représentaient environ 80%, et le reste était des erreurs de manipulation de mémoire, des erreurs algorithmiques et des bugs de concurrence.
Le taux d’erreurs était plus élevé dans les langages comme C, C++, JavaScript, Objective-C et Php, et moins élevé dans les langages Clojure, Haskell, Ruby, Scala et TypeScript. Cela a permis à ceux-ci de conclure que les langages de programmation fonctionnels pourraient être « mieux » que les langages de programmation procéduraux.
Cependant, ces effets modestes découlant de la conception du langage de programmation sont rapidement dominés par des facteurs tels que la taille du projet, la taille de l’équipe, etc. rendant leur impact moins significatif.
Au final, la qualité d’une application serait plus liée au facteur humain, qu’au langage de programmation utilisé. Quel que soit le langage utilisé, ce sont les aptitudes de développeurs derrière le code qui a été écrit et la taille du projet qui permettent de faire la différence.
Source : L'étude au format PDF
Et vous ?
Qu’en pensez-vous ? Pour vous, le langage de programmation a-t-il un effet important sur la qualité du code ?
D’aucuns affirmeront que le langage qu’ils utilisent permet d’obtenir un code de meilleure qualité, plus lisible et facilement maintenable. D’autres que leur langage offre plus de sécurité, permet d’avoir moins de bugs, etc. Bref, chacun sortira des arguments pour défendre avec conviction le langage de programmation qu’il utilise. Au final, on se rendra probablement compte que le débat est beaucoup plus religieux que scientifique.
Pourtant, les différences au niveau de la qualité de code entre les langages de programmation sont assez petites. C’est la conclusion d’une étude réalisée par des informaticiens de l’université de Californie, qui sera présentée ce mois lors d’un colloque à Hong Kong sur le génie logiciel.
L’étude a été faite en utilisant un ensemble très vaste de données disponibles sur GitHub. Les chercheurs ont analysé 729 projets, environ 80 millions de lignes de code de 29 000 auteurs et 1,7 million de commits, dans 17 langages de programmation.
Au vu de la grande taille de l’échantillon, les chercheurs ont utilisé une approche de « méthodes mixtes », combinant un modèle de régression multiple avec l’analyse de texte, le regroupement et la visualisation.
Ils ont constaté, par exemple, que le typage fort est légèrement meilleur que le typage faible. Que pour les langages fonctionnels, le typage statique était légèrement mieux que le typage dynamique.
En analysant les erreurs génériques en programmation, ceux-ci ont constaté une domination des fautes de frappe, des erreurs de type, des erreurs de compilation, d’initialisation des données, etc. Ces erreurs représentaient environ 80%, et le reste était des erreurs de manipulation de mémoire, des erreurs algorithmiques et des bugs de concurrence.
Le taux d’erreurs était plus élevé dans les langages comme C, C++, JavaScript, Objective-C et Php, et moins élevé dans les langages Clojure, Haskell, Ruby, Scala et TypeScript. Cela a permis à ceux-ci de conclure que les langages de programmation fonctionnels pourraient être « mieux » que les langages de programmation procéduraux.
Cependant, ces effets modestes découlant de la conception du langage de programmation sont rapidement dominés par des facteurs tels que la taille du projet, la taille de l’équipe, etc. rendant leur impact moins significatif.
Au final, la qualité d’une application serait plus liée au facteur humain, qu’au langage de programmation utilisé. Quel que soit le langage utilisé, ce sont les aptitudes de développeurs derrière le code qui a été écrit et la taille du projet qui permettent de faire la différence.
Source : L'étude au format PDF
Et vous ?
-
macslanMembre éclairéComme le dis si bien mon père rien ne sert d'avoir une Ferrari si c'est un âne qui conduitle 06/11/2014 à 15:42
-
atha2Membre éprouvéComme tout le monde, je suis d'accord, la qualité d'un projet est plus liée au développeur qu'au langage. Mais le bon choix du langage apporte une aide qu'il serait dommage de ne utiliser.
Pour les DSL (Domain Specific Languages) comme SQL, HTML et PHP, je suis d'accord.
Pour les autres langages, le gain de productivité passe justement par l'anticipation des bugs par le langage.- static vs dynamic => erreur détectée à la compilation plutôt qu'a l’exécution.
- typage fort vs faible => rend plus clair le résultat d'une expression (e.g. 1 + "2" donne "12" ou "3"
. - langage fonctionnel => pas d'effet de bord.
- mémoire managée => pas de fuite de mémoire.
Même si ces éléments n'impactent pas forcément la qualité du logiciel final (et peuvent introduire des désavantages niveau performance (mémoire managée), lourdeur de la syntaxe...), en l'absence de test unitaire, une fonction aura plus de chance de contenir un bug sans ces aides apportés par le langage.
Par contre plusieurs choses me gênent dans cette étude :
- la qualité d'un projet est vraiment liée directement au nombre de bug ? La facilité d'évolution du projet n'est pas un critère important ? (oui !)
- certains langages n'ont-il pas tendance à attirer/repousser les débutants/développeurs experimentés ?
le 06/11/2014 à 22:59 -
yahikoRédacteur/ModérateurUn nouveau langage est surtout motivé par la capacité à être plus productif sur un domaine, pas vraiment par la qualité du code.
Si on a majoritairement abandonné la programmation en assembleur depuis belle lurette, c'est d'abord parce que programmer en assembleur est beaucoup moins productif que de programmer dans des langages dits de plus haut niveau.le 06/11/2014 à 17:36 -
_skipExpert éminentAprès avoir survolé la méthodologie employée pour les bugs, soit analyse des commit logs (10%) par machine, je dirai qu'il y a quand même un "bruit" non négligeable si on enlève déjà la forte disparité entre les projets et les philosophies de source control (il y a des gens qui commitent que des choses parfaitement testées, d'autres pas). Il aurait fallu ne prendre en compte que les branches de maintenance.
Envoyé par Traroth2
Il y a une disparité extrême entre les projets Github, la méthode pour qualifier des "erreurs" est loin d'être extrêmement solide. En gros j'ai l'impression que c'est une étude à laquelle on pardonne le procédé un peu douteux sous prétexte que les conclusions font l'unanimité de fait. Ben oui qui irait dire que la compétence du développeur n'est pas un facteur décisif de la qualité d'un code? Si une étude conclut que le filet mignon c'est meilleur que du pied de porc, vous allez certainement la croire, peu importe la méthodologie.
Si ce qu'on doit tirer du résultat de cette étude c'est qu'au final tout se vaut, personnellement je suis pas d'accord. Il y a des langages plus productifs, plus sécurisés que d'autres, parfois avec d'autres compromis. Etre plus productif peut amener plus d'imperfections, mais peut être également plus de temps pour le test et les finitions, le typage statique peut parfois être un peu boulet mais au final jouer un rôle positif sur la maintenance, bref la façon dont s'imbriquent les différents facteurs + et - n'est pas facile à déterminer. De plus, dans chaque techno il y a des écosystèmes de qualité variable qui sont à prendre en compte.le 07/11/2014 à 8:33 -
Juda-PriestMembre actifAu final, la qualité d’une application serait plus liée au facteur humain, qu’au langage de programmation utilisé. Quel que soit le langage utilisé, ce sont les aptitudes de développeurs derrière le code qui a été écrit et la taille du projet qui permettent de faire la différence.le 06/11/2014 à 15:48
-
DarkzinusExpert éminent séniorRien de neuf sous le soleil en sommele 06/11/2014 à 15:43
-
OrhleilMembre habituéAu final, la qualité d’une application serait plus liée au facteur humain, qu’au langage de programmation utilisé. Quel que soit le langage utilisé, ce sont les aptitudes de développeurs derrière le code qui a été écrit et la taille du projet qui permettent de faire la différence.
Ceci étant dit, la question posée par les chercheurs est assez légitime. Et après la conclusion citée juste au-dessus je m'interroge sincèrement sur les limites que nous pouvons avoir en matière de qualité de code. Est-il théoriquement possible de créer un langage si bien organisé que les erreurs sont impossibles ? La méthode B est supposée s'en rapprocher mais au final si le concepteur omet ne serait-ce qu'un détail le code comportera des failles.
Je crois que globalement, et c'est d'ailleurs la méthodologie appliquée aujourd'hui, on se moque un peu de la qualité du code dans la majorité des cas.
Quand on regarde bien la plupart des programmes n'ont soit aucune soit très peu de contraintes à respecter (soit délai, soit espace mémoire, soit failles de sécurité critiques, le plus souvent). Quand j'utilise mon casque audio bluetooth, il fonctionne sur un programme qui doit être réactif et assez peu gourmand en mémoire, mais la sécurité logicielle de l'engin je m'en tamponne royalement par exemple. Il suffit de savoir quels sont les objectifs clés que l'on cherche à atteindre sans vouloir pour autant décrocher la Lune, et si on est pas trop mauvais on arrive à coder un truc qui fait le bon taff dans des critères de qualité acceptables, et c'est bien là l'essentiel.le 06/11/2014 à 16:20 -
el_slapperExpert éminent séniorL'interêt d'un nouveau langage est de coller à un besoin précis. COBOL, C ou LISP pour faire ce que fait Javascript, bofbofbof.le 06/11/2014 à 17:24
-
NSKisEn attente de confirmation mail
Pour résumer la démarche, ils ont pris des lignes de code de différents langages et ont comptabilisé les erreurs de programmation?
Pour que leur travail soit sérieux, ils ont donc détecté ces erreurs de manière exhaustive et complète.
De sacrés champions! Ils devraient plutôt se consacrer au développement!!! Vous imaginez la qualité de leur code? Une vraie merveille!
Ah moins que...le 06/11/2014 à 19:20 -
MidoCESIMembre à l'essaiAu final, la qualité d’une application serait plus liée au facteur humain, qu’au langage de programmation utilisé. Quel que soit le langage utilisé, ce sont les aptitudes de développeurs derrière le code qui a été écrit et la taille du projet qui permettent de faire la différence.le 06/11/2014 à 15:49