Lignes de code source

Le nombre de lignes de code source ( SLOC ), également appelé lignes de code ( LOC ), est une métrique logicielle permettant de mesurer la taille d'un programme informatique en comptant le nombre de lignes de son code source . Le SLOC est généralement utilisé pour estimer l'effort nécessaire au développement d'un programme, ainsi que la productivité et la maintenabilité du logiciel une fois produit.

De nombreuses comparaisons pertinentes se basent uniquement sur l' ordre de grandeur du nombre de lignes de code d'un projet. Comparer un projet de 10 000 lignes de code à un projet de 100 000 lignes est bien plus utile que de comparer un projet de 20 000 lignes à un projet de 21 000 lignes. Bien que la méthode de mesure du nombre de lignes de code puisse faire débat, des écarts d'un ordre de grandeur peuvent clairement indiquer la complexité du logiciel ou le temps de développement .

Il existe deux grands types de mesures SLOC : les SLOC physiques (LOC) et les SLOC logiques (LLOC). Les définitions précises de ces deux mesures varient, mais la définition la plus courante des SLOC physiques est le nombre de lignes du code source du programme, à l’exclusion des lignes de commentaires.

Le SLOC logique tente de mesurer le nombre d'« instructions » exécutables, mais sa définition précise est liée à chaque langage informatique (une mesure simple du SLOC logique pour les langages de type C est le nombre de points-virgules en fin d'instruction). Il est beaucoup plus facile de créer des outils pour mesurer le SLOC physique, et sa définition est plus simple à expliquer. Cependant, les mesures du SLOC physique sont plus sensibles aux conventions de formatage et de style non pertinentes que celles du SLOC logique. Or, les mesures du SLOC sont souvent présentées sans définition, et le SLOC logique peut différer sensiblement du SLOC physique.

Considérons cet extrait de code C comme un exemple de l'ambiguïté rencontrée lors de la détermination du nombre de lignes de code source (SLOC) :

for ( int i = 0 ; i < 100 ; i ++ ) printf ( "hello" ); /* afficher cent salutations */

Dans cet exemple, nous avons :

• 1 ligne de code physique (LOC),
• 2 lignes de code logiques (LLOC) ( instruction for et instruction printf ),
• 1 ligne de commentaire.

Selon le programmeur et les normes de codage, la « ligne » de code ci-dessus pourrait être écrite sur plusieurs lignes distinctes :

/* afficher cent salutations */ for ( int i = 0 ; i < 100 ; i ++ ) { printf ( "bonjour" ); }

Dans cet exemple, nous avons :

• 4 lignes de code physiques (LOC) : le travail de pose d'accolades doit-il être estimé ?
• 2 lignes de code logiques (LLOC) : qu'en est-il de tout le travail d'écriture des lignes qui ne sont pas des instructions ?
• 1 ligne de commentaire : les outils doivent prendre en compte l’intégralité du code et des commentaires, quel que soit l’emplacement de ces derniers.

Même les valeurs SLOC « logiques » et « physiques » peuvent avoir de nombreuses définitions différentes. Robert E. Park (alors au Software Engineering Institute ) et d'autres ont élaboré un cadre de définition des valeurs SLOC, afin de permettre d'expliquer et de définir précisément la mesure SLOC utilisée dans un projet. Par exemple, la plupart des systèmes logiciels réutilisent du code, et il est important de déterminer quel code réutilisé (le cas échéant) inclure lors du calcul d'une mesure.

À l'époque où le SLOC (Single Line of Codes) a été introduit comme métrique, les langages les plus courants, tels que FORTRAN et le langage assembleur , étaient des langages orientés lignes. Ces langages ont été développés à une époque où les cartes perforées constituaient le principal moyen de saisie de données pour la programmation. Une carte perforée représentait généralement une ligne de code. Il s'agissait d'un objet discret, facile à compter. Ce résultat visible du programmeur justifiait que les responsables comptent les lignes de code comme indicateur de productivité, allant jusqu'à parler d'« images de cartes ». Aujourd'hui, les langages informatiques les plus utilisés offrent une bien plus grande flexibilité en matière de formatage. Les lignes de texte ne sont plus limitées à 80 ou 96 colonnes, et une ligne de texte ne correspond plus nécessairement à une ligne de code.

Les mesures SLOC sont quelque peu controversées, notamment en raison de leur utilisation parfois abusive. Des expériences ont confirmé à maintes reprises la forte corrélation entre l'effort et le nombre de lignes de code (SLOC) : les programmes avec un SLOC plus élevé prennent plus de temps à développer. Le SLOC peut donc être un indicateur efficace de l'effort. Cependant, la fonctionnalité est moins bien corrélée au SLOC : des développeurs expérimentés peuvent développer la même fonctionnalité avec beaucoup moins de code, si bien qu'un programme avec moins de SLOC peut offrir plus de fonctionnalités qu'un autre programme similaire. Utiliser le SLOC comme mesure de productivité présente des limites, car un développeur peut n'écrire que quelques lignes et être pourtant bien plus productif en termes de fonctionnalités qu'un développeur qui finit par en écrire davantage (et qui, généralement, y consacre plus d'efforts). Les bons développeurs peuvent fusionner plusieurs modules de code en un seul, améliorant ainsi le système, mais donnant l'impression d'une productivité négative puisqu'ils suppriment du code. De plus, les développeurs inexpérimentés ont souvent recours à la duplication de code , une pratique fortement déconseillée car plus sujette aux bogues et plus coûteuse à maintenir, mais qui entraîne un SLOC plus élevé.

Le comptage des lignes de code système (SLOC) présente des problèmes de précision supplémentaires lors de la comparaison de programmes écrits dans différents langages, à moins d'appliquer des facteurs d'ajustement pour normaliser ces langages. Les différents langages informatiques trouvent un équilibre entre concision et clarté de manières diverses ; à titre d'exemple extrême, la plupart des langages assembleur nécessiteraient des centaines de lignes de code pour accomplir la même tâche que quelques caractères en APL . L'exemple suivant compare un programme « Hello World » écrit en BASIC , en C et en COBOL (un langage réputé pour sa verbosité).

Un autre problème de plus en plus fréquent dans la comparaison des métriques SLOC réside dans la différence entre le code généré automatiquement et le code écrit manuellement. Les outils logiciels modernes permettent souvent de générer automatiquement d'énormes quantités de code en quelques clics. Par exemple, les outils de création d'interfaces graphiques génèrent automatiquement tout le code source d'un élément de contrôle graphique par simple glisser-déposer d'une icône dans l'espace de travail. Le travail nécessaire à la création de ce code ne peut être comparé à celui requis pour écrire un pilote de périphérique , par exemple. De même, une classe d'interface graphique personnalisée, écrite manuellement, peut facilement s'avérer plus complexe qu'un simple pilote de périphérique ; d'où les limites de cette métrique.

Plusieurs modèles d'estimation des coûts, des délais et des efforts utilisent les SLOC comme paramètre d'entrée, notamment la série de modèles COCOMO (Constructive Cost Model) de Barry Boehm et al., PRICE Systems True S et SEER-SEM de Galorath . Bien que ces modèles présentent une bonne capacité prédictive, leur performance dépend de la qualité des estimations qui leur sont fournies (en particulier celles des SLOC). De nombreux auteurs préconisent l'utilisation des points de fonction plutôt que des SLOC comme mesure de fonctionnalité, mais cette approche ne fait pas l'unanimité, car les points de fonction sont fortement corrélés aux SLOC (et ne peuvent être mesurés automatiquement).

Selon Vincent Maraia, les valeurs SLOC pour divers systèmes d'exploitation de la gamme de produits Windows NT de Microsoft sont les suivantes :

David A. Wheeler a étudié la distribution Red Hat du système d'exploitation Linux et a indiqué que Red Hat Linux version 7.1 (publiée en avril 2001) contenait plus de 30 millions de lignes de code source physiques. Il a également extrapolé que, si elle avait été développée par des moyens propriétaires conventionnels, elle aurait nécessité environ 8 000 années-personnes de travail de développement et aurait coûté plus d'un milliard de dollars (en dollars américains de l'an 2000).

Une étude similaire a ensuite été menée sur Debian GNU/Linux version 2.2 (également connue sous le nom de « Potato »), un système d'exploitation initialement publié en août 2000. Cette étude a révélé que Debian GNU/Linux 2.2 comprenait plus de 55 millions de lignes de code source (SLOC) et que son développement, s'il avait été réalisé de manière propriétaire classique, aurait nécessité 14 005 années-personnes et un coût de 1,9 milliard de dollars américains. Des analyses ultérieures des outils utilisés indiquent que la version suivante de Debian comptait 104 millions de lignes de code source et, en 2005, la dernière version en comptait plus de 213 millions.

1. Possibilités d'automatisation du comptage : une ligne de code étant une entité physique, l'automatisation du comptage permet d'éliminer facilement le travail manuel. De petits utilitaires peuvent être développés pour compter les lignes de code d'un programme. Cependant, un utilitaire de comptage logique conçu pour un langage spécifique ne peut être utilisé pour d'autres langages en raison des différences syntaxiques et structurelles. Des compteurs physiques de lignes de code, compatibles avec des dizaines de langages, existent néanmoins.
2. Une métrique intuitive : le nombre de lignes de code (LOC) est une métrique intuitive pour mesurer la taille d'un logiciel, car il est visible et son impact est facilement perceptible. Les points de fonction, quant à eux, sont considérés comme une métrique plus objective, non tangible, existant uniquement dans l'espace logique. Ainsi, le LOC s'avère pratique pour exprimer la taille d'un logiciel, notamment pour les programmeurs moins expérimentés.
3. Mesure omniprésente : les mesures LOC existent depuis les débuts du logiciel. De ce fait, on peut affirmer que les données LOC sont plus nombreuses que pour toute autre mesure de taille.

1. Manque de responsabilisation : la mesure du nombre de lignes de code présente des problèmes fondamentaux. Certains estiment qu’il est inutile de mesurer la productivité d’un projet en se basant uniquement sur les résultats de la phase de codage, qui ne représente généralement que 30 à 35 % de l’effort total.
2. Manque de cohérence avec les fonctionnalités : bien que des expériences aient confirmé à maintes reprises que l’effort est fortement corrélé au nombre de lignes de code (LOC), la fonctionnalité l’est beaucoup moins. Autrement dit, des développeurs expérimentés peuvent développer les mêmes fonctionnalités avec beaucoup moins de code ; un programme avec moins de lignes de code peut donc offrir plus de fonctionnalités qu’un autre programme similaire. En particulier, le nombre de lignes de code est un mauvais indicateur de productivité individuelle, car un développeur qui n’écrit que quelques lignes peut être plus productif qu’un développeur qui en écrit davantage – et même davantage : un refactoring efficace, comme l’extraction de méthodes pour supprimer le code redondant et maintenir un code propre, réduira considérablement le nombre de lignes de code.
3. Impact négatif sur l'estimation : en raison du fait présenté au point n° 1, les estimations basées sur des lignes de code peuvent s'avérer erronées, dans toutes les possibilités.
4. L'expérience du développeur influence la mise en œuvre d'une logique spécifique, qui varie selon son niveau d'expérience. Par conséquent, le nombre de lignes de code diffère d'une personne à l'autre. Un développeur expérimenté peut implémenter une fonctionnalité donnée avec moins de lignes de code qu'un développeur moins expérimenté, même s'ils utilisent le même langage.
5. Différences de langages : prenons deux applications offrant les mêmes fonctionnalités (écrans, rapports, bases de données). L’une est écrite en C++ et l’autre dans un langage comme COBOL. Le nombre de points de fonction est identique, mais certains aspects de l’application diffèrent. Le nombre de lignes de code nécessaires à leur développement est donc différent. Par conséquent, l’effort requis pour développer l’application (en heures par point de fonction) est également différent. Contrairement au nombre de lignes de code, le nombre de points de fonction reste constant.
6. L'avènement des interfaces graphiques : avec l'apparition des langages et outils de programmation à interface graphique, tels que Visual Basic , les programmeurs peuvent écrire relativement peu de code tout en obtenant un haut niveau de fonctionnalités. Par exemple, au lieu d'écrire un programme pour créer une fenêtre et dessiner un bouton, un utilisateur disposant d'une interface graphique peut utiliser le glisser-déposer et d'autres actions à la souris pour placer des composants dans un espace de travail. Le code généré automatiquement par une interface graphique n'est généralement pas pris en compte lors de l'utilisation des méthodes de mesure en lignes de code (LOC). Cela engendre des variations entre les langages ; une même tâche pouvant être réalisée en une seule ligne de code (voire sans code du tout) dans un langage peut nécessiter plusieurs lignes de code dans un autre.
7. Problèmes liés au multilinguisme : dans le contexte actuel du développement logiciel, il est fréquent que les logiciels soient développés dans plusieurs langages. Très souvent, plusieurs langages sont utilisés en fonction de la complexité et des exigences. Le suivi et le reporting de la productivité et des taux de défauts constituent alors un problème majeur, car les défauts ne peuvent plus être attribués à un langage particulier après l’intégration du système. Les points de fonction s’avèrent être la meilleure mesure de la taille du système dans ce cas.
8. Absence de normes de comptage : il n’existe pas de définition standard de ce qu’est une ligne de code. Les commentaires sont-ils comptabilisés ? Les déclarations de données sont-elles incluses ? Que se passe-t-il si une instruction s’étend sur plusieurs lignes ? – Ce sont là des questions qui se posent fréquemment. Bien que des organisations comme le SEI et l’IEEE aient publié des recommandations pour tenter de standardiser le comptage, leur mise en œuvre s’avère complexe, notamment face à l’apparition constante de nouveaux langages de programmation.
9. Psychologie : un programmeur dont la productivité est mesurée en lignes de code sera incité à écrire un code inutilement verbeux. Plus la direction se concentre sur le nombre de lignes de code, plus le programmeur est incité à complexifier inutilement son code. Ceci est problématique, car une complexité accrue peut entraîner une augmentation des coûts de maintenance et des efforts nécessaires à la correction des bogues.

Dans le documentaire de PBS intitulé Triumph of the Nerds , Steve Ballmer, futur cadre de Microsoft, a critiqué l'utilisation du comptage des lignes de code :

Chez IBM, il y a une sorte de religion dans le développement logiciel qui impose de compter les K-LOC, et un K-LOC équivaut à mille lignes de code. « C'est quoi un projet ? » « Ah, un projet à 10 000 LOC. » « Celui-ci en fait 20 000. » « Et celui-là, 50 000. » IBM voulait en faire la norme pour notre rémunération. On nous demandait combien on gagnait avec OS/2 , combien ils en faisaient. « Combien de K-LOC avez-vous écrit ? » On essayait sans cesse de les convaincre : « Si un développeur a une bonne idée et qu'il peut la réaliser en 4 000 LOC au lieu de 20 000, est-ce qu'on devrait être moins payés ? Parce qu'il a créé quelque chose de plus petit et de plus rapide, avec moins de K-LOC. » K-LOC, K-LOC, voilà la méthode ! Pfff ! Bref, rien que d'y penser, ça me donne des frissons.

Selon le Computer History Museum, Bill Atkinson, développeur chez Apple, a constaté des problèmes liés à cette pratique en 1982 :

En 1982, alors que l'équipe Lisa s'efforçait de finaliser son logiciel, les chefs de projet ont commencé à exiger des programmeurs qu'ils soumettent chaque semaine un formulaire indiquant le nombre de lignes de code écrites. Bill Atkinson trouvait cela absurde. La semaine où il avait réécrit les routines de calcul de région de QuickDraw pour les rendre six fois plus rapides et 2 000 lignes plus courtes, il a inscrit « -2000 » sur le formulaire. Après quelques semaines, les responsables ont cessé de lui demander de remplir ce formulaire, et il s'y est conformé avec plaisir.