Quand, si jamais, est "Nombre de lignes de code" une métrique utile?
Certaines personnes affirment que le pire ennemi du code est sa taille et j'ai tendance à être d'accord. Pourtant, chaque jour, vous continuez à entendre des choses comme
- J'écris bla lignes de code dans une journée.
- Je possède X lignes de code.
- Windows est x millions de lignes de code.
Question: Quand est-ce que "#lines du code" utile?
pS: Notez que lorsque de telles instructions sont effectuées, la tonalité est "davantage est meilleure".
Je dirais que c'est lorsque vous êtes Supprimer code pour que le projet fonctionne mieux.
Dire que vous avez supprimé "x nombre de lignes" est impressionnant. Et beaucoup plus utile que vous avez ajouté des lignes de code.
Je suis surpris que personne n'a mentionné le célèbre citation de Dijkstra, alors voilà:
Mon point d'aujourd'hui est que, si nous souhaitons compter des lignes de code, nous ne devrions pas les considérer comme des "lignes produites" mais "lignes passées": la sagesse conventionnelle actuelle est tellement stupide de réserver qui comptent sur le mauvais côté de la registre.
La citation provient d'un article appelé " sur la cruauté de vraiment enseigner la science informatique ".
C'est une terrible métrique, mais comme l'a noté d'autres personnes, cela vous donne une idée (très) approximative de la complexité globale d'un système. Si vous comparez deux projets, A et B et A sont 10 000 lignes de code, et B est de 20 000, cela ne vous dit pas beaucoup - le projet B pourrait être excessivement verbeux, ou pourrait être super-comprimé.
D'autre part, si un projet est de 10 000 lignes de code, l'autre est de 1 000 000 lignes, le deuxième projet est nettement plus complexe, en général.
Les problèmes de cette métrique entrent lorsqu'il est utilisé pour évaluer la productivité ou le niveau de contribution à un projet. Si le programmeur "x" écrit 2x le nombre de lignes comme programmateur 'y ", il pourrait ou non contribuer davantage - peut-être que" y "travaille sur un problème plus difficile ...
Quand se vanter à des amis.
Au moins, pas pour le progrès:
"La mesure de la programmation Les progrès réalisés par des lignes de code sont comme mesurer les progrès de la construction d'aéronefs en poids." --Bill Gates
Il est utile lors du chargement de votre imprimante de ligne, de sorte que vous sachiez combien de pages la liste de code que vous êtes sur le point d'imprimer consomme. ;)
Il y a un cas particulier quand je le trouve inestimable. Lorsque vous êtes dans une interview et qu'ils vous disent que la partie de votre travail sera de maintenir un C++/Perl/Java existant/etc. Projet hérité. Demander à l'intervieweur combien de KLOC (environ) sont impliqués dans le projet Legacy vous donneront une meilleure idée de savoir si vous voulez leur travail ou non.
comme la plupart des métriques, ils signifient très peu sans contexte. Donc, la réponse courte est la suivante: jamais (sauf pour l'imprimante ligne, c'est drôle! Qui imprime des programmes ces jours-ci?)
Un exemple:
Imaginez que vous soyez un appareil-test et refactorise le code hérité. Il commence avec 50 000 lignes de code (50 kloc) et 1 000 bogues démontrables (tests d'unité ayant échoué). Le rapport est 1k/50kloc = 1 bug pour 50 lignes de code. Clairement c'est terrible code!
Maintenant, plusieurs itérations plus tard, vous avez réduit les bugs connus de moitié (et les bugs inconnus de plus que ceux qui sont probablement) et la base de code d'un facteur de cinq au refactoring exemplaire. Le rapport est maintenant 500/10000 = 1 bug pour 20 lignes de code. Ce qui est apparemment encore pire!
En fonction de l'impression que vous souhaitez faire, cela peut être présenté comme un ou plusieurs des éléments suivants:
- 50% moins de bugs
- cinq fois moins de code
- 80% moins de code
- 60% d'aggravation du rapport Bugs-Code
tous sont vrais (en supposant que je n'ai pas bousillé les mathématiques), et ils sucer en résumant la grande amélioration qu'un tel effort de refactorisation doit avoir atteint.
Pour paraphraser une citation que j'ai lu il y a environ 25 ans,
"Le problème avec l'utilisation de lignes de code en tant que métrique est qu'il mesure la complexité de la solution, pas la complexité du problème".
Je crois que la citation provient de David Parnas dans un article du Journal of the ACM.
Me rappelle ceci:
La lettre actuelle est très longue, simplement parce que je n'avais pas de loisir pour le rendre plus court.
--Blaise Pascal.
Réponse: Lorsque vous pouvez parler de lignes de code négatives. Comme dans: "J'ai supprimé 40 lignes de code extrêmes aujourd'hui et le programme fonctionne toujours aussi bien qu'auparavant."
Il y a beaucoup de différences métriques logicielles . Les lignes de code sont les plus utilisées et sont les plus faciles à comprendre.
Je suis surpris à quelle fréquence les lignes de la métrique de code corrélent avec les autres métriques. Au lieu d'acheter un outil capable de calculer la complexité cyclomatique pour découvrir les odeurs de code, je cherche simplement les méthodes avec de nombreuses lignes et ils ont tendance à avoir une grande complexité.
Un bon exemple d'utilisation des lignes de code est dans la métrique: des bugs par lignes de code. Cela peut vous donner une sensation de gut du nombre de bugs à trouver dans votre projet. Dans mon organisation, nous sommes généralement autour de 20 bugs pour 1000 lignes de code. Cela signifie que si nous sommes prêts à expédier un produit contenant 100 000 lignes de code, et notre base de données de bugs montre que nous avons trouvé 50 bugs, nous devrions probablement faire plus de tests supplémentaires. Si nous avons 20 bugs pour 1000 lignes de code, nous approchons probablement de la qualité que nous sommes habituellement.
Un mauvais exemple d'utilisation est de mesurer la productivité du développeur. Si vous mesurez la productivité des développeurs par des lignes de code, les gens ont tendance à utiliser plus de lignes pour fournir moins.
J'accepterais que prendre le nombre total de lignes de code dans un projet est d'une manière à mesurer complexité.
Ce n'est certainement pas la seule mesure de la complexité. Par exemple, le débogage d'un script perl obscurposé de 100 lignes est très différent de déboguer une ligne de 5 000 lignes Java Projet avec des modèles de commentaire.
Mais sans regarder la source, vous pensez généralement que davantage de lignes de code sont plus complexes, tout comme vous pourriez penser qu'une boucle source de 10 Mo est plus complexe qu'une citation source de 15 ko.
C'est utile à bien des égards.
Je ne me souviens pas de # exactement # mais Microsoft avait une boîte de distribution qui a parlé de chaque X lignes de code en moyenne il y a un nombre de bugs. Vous pouvez prendre cette déclaration et l'utiliser pour donner une base de référence pour plusieurs choses.
- Dans quelle mesure un critique de code fait-il leur travail.
- jugement de niveau de compétence de 2 employés en comparant leur ratio de bogues sur plusieurs projets.
Une autre chose que nous regardons est, pourquoi est-ce tellement de lignes? Souvent, lorsqu'un nouveau programmeur est mis dans une confiture, il suffira de copier et de coller des morceaux de code au lieu de créer des fonctions et d'encapsuler.
Je pense que j'ai écrit X lignes de code dans une journée est une mesure terrible. Cela ne tient pas compte de la difficulté de problèmes, de la langue dans votre écriture, etc.
Il me semble qu'il y a une limite finie du nombre de lignes de code que je peux faire référence au sommet de ma tête à partir de tout projet donné. La limite est probablement très similaire pour le programmeur moyen. Par conséquent, si vous connaissez votre projet comporte 2 millions de lignes de code et que vos programmeurs peuvent être en mesure de comprendre si un bogue est lié ou non sur les lignes de code 5K, ils savent bien, vous savez que vous devez embaucher 400 Les programmeurs pour votre base de code doivent être bien couverts de la mémoire de quelqu'un.
Cela vous fera également réfléchir à deux fois sur la croissance de votre base de code trop rapide et vous pourriez vous faire penser à le refléter pour le rendre plus compréhensible.
NOTE I Fabriquée ces chiffres.
Les lignes de code sont utiles pour savoir quand vous vous demandez si un fichier de code devient trop grand. Hmmm ... ce fichier est maintenant 5000 lignes de code. Peut-être que je devrais refracter cela.
C'est une métrique de productivité, ainsi que la complexité. Comme toutes les métriques, il doit être évalué avec soin. Une seule métrique n'est généralement pas suffisante pour une réponse complète.
C'est-à-dire qu'un programme de 500 lignes n'est pas aussi complexe qu'une ligne 5000. Maintenant, vous devez poser d'autres questions pour mieux visualiser le programme ... mais maintenant vous avez une métrique.
Il est une grande mesure pour faire peur/impressionner les gens. C'est à ce sujet, et certainement le contexte que je vois dans les trois exemples.
J'ai écrit 2 billet de blog détaillage le pro et le contre de comptage de lignes de code (LoC):
Comment comptez-vous votre nombre de lignes de code (LOC)? : L'idée est d'expliquer que vous devez compter le nombre logique de lignes de code au lieu d'un décompte physique. Pour ce faire, vous pouvez utiliser des outils comme NDepend par exemple.
[. .____] Pourquoi est-il utile de compter le nombre de lignes de code (LOC)? : L'idée est que LoC ne doit jamais être utilisé pour mesurer la productivité, mais plus pour faire une estimation de la couverture des tests et l'estimation de la date limite du logiciel.
Lorsque vous devez budgétiser le nombre de cartes de poinçon, vous devez commander.
Le profil de maturité de la communauté logicielle de l'institut d'ingénierie logiciel de la communauté logicielle: Mise à jour finale de 1998 (que je n'ai pas pu trouver de lien avec, malheureusement) discute d'une enquête d'environ 800 équipes de développement de logiciels (ou peut-être c'était peut-être des magasins). La densité moyenne des défauts était de 12 défauts par 1000 loc.
Si vous aviez une application avec 0 défauts (cela n'existe pas en réalité, mais supposons) et a écrit 1000 loc, en moyenne, vous pouvez supposer que vous venez d'introduire 12 défauts dans le système. Si QA trouve 1 ou 2 défauts et c'est tout, ils doivent faire plus de tests car il y a probablement plus de 10 plus de défauts.
C'est une idée très utile lorsqu'il est associé au nombre de défauts. "Défauts" vous donne une mesure de la qualité du code. Le moins "défaut" mieux le logiciel; Il est presque impossible de supprimer tous les défauts. À de nombreuses reprises, un seul défaut pourrait être nocif et fatal.
Cependant, il ne semble pas que le logiciel nondéfectif existe.
Lorsque vous refactez une base de code et que vous pouvez montrer que vous supprimés lignes de code et tous les tests de régression sont toujours passés.
Découvrez la définition de Wikipedia: http://fr.wikipedia.org/wiki/source_lines_of_code
SLOC = 'Source Lines de code'
Il y a en fait un peu de temps dans ces métriques où je travaille. Il existe également différentes façons de compter SLOC.
De l'article Wikipedia:
Il existe deux principaux types de mesures SLOC: SLOC physique et SLOC logique.
Une autre bonne ressource: http://www.dwwheeler.com/sloc/
Les lignes de code ne sont pas vraiment utiles et si elle est utilisée comme une métrique par la direction, cela conduit à des programmeurs à faire beaucoup de refactorisation pour renforcer leurs scores. En outre, les algorithmes pauvres ne sont pas remplacés par des algorithmes courts soignés, car cela conduit à un nombre local négatif qui compte contre vous. Pour être honnête, il suffit de ne pas travailler pour une entreprise qui utilise LOC/D en tant que métrique de productivité, car la gestion n'a clairement aucune idée du développement logiciel et vous serez donc toujours sur le pied arrière du premier jour.
Lorsque vous soulignez pourquoi le changement va prendre si longtemps.
"Windows est de 7 millions de lignes de code et il faut un certain temps pour tester toutes les dépendances ..."
Dans les compétitions.
Lorsque le codeur ne sait pas que vous comptez des lignes de code, aucune raison n'a aucune raison d'ajouter délibérément du code redondant au jeu. Et lorsque tout le monde dans l'équipe a un style de codage similaire (il existe donc une "valeur" moyenne connue par ligne.) Et seulement si vous n'avez pas de meilleure mesure disponible.
Lors de la détermination du niveau d'effort (LOE). Si vous mettez une proposition et vous aurez à peu près les mêmes ingénieurs travaillant sur le nouveau projet, vous pourrez peut-être déterminer combien d'ingénieurs sont nécessaires pendant combien de temps.
Je l'ai trouvé utile dans deux conditions:
Jauger ma propre productivité sur mon propre nouveau projet quand il dirige le temps de codage.
Lorsque vous travaillez avec une grande entreprise et parlant avec un gestionnaire qui ne comprend vraiment que les widgets par jour.
J'ai entendu dire que Microsoft acheminé 5% des personnes tous les 6 mois, j'ai toujours imaginé que cela serait basé sur des lignes de code écrites, c'est pourquoi Windows est si encombrante, lente et inefficace;). Les lignes de code sont une métrique utile pour mesurer la complexité d'une application en termes de commande approximative, c'est-à-dire un programme débutant de base pourraient être 10 lignes de code, 100 lignes de code est une application de jouets, 50000 lignes sont une application de taille raisonnable, 10 millions de lignes de code est une monstruosité appelée Windows.
Les lignes de code ne sont pas une métrique très utile cependant, je manquais à écrire des jeux dans la langue d'assemblage (principalement), ils mesuraient dans environ 50 000 lignes de code, mais j'ai gardé le nombre de lignes de code de code en ne poussant pas à pousser des registres à la empiler et garder une trace de ce qui était contenu dans les registres pour réduire la taille du code (les autres programmeurs que je savais ont fait un multiple poussé de D0-D7, A0-A6 à la pile, ce qui ralentit évidemment le code, mais simplifie la suivie ce qui est affecté).
Fonctionnellement jamais, mis à part le but "vernissant" mentionné précédemment.
Lignes! = Efficacité. Souvent, la relation est inverse, dans mon expérience (bien que non strictement, surtout pour l'extrême, pour des raisons évidentes)
Il peut s'agir d'une très bonne mesure de complexité aux fins de l'évaluation des risques - plus les lignes ont changé de plus grandes les chances d'introduire un bogue.
Cela peut être utile lors de la comparaison des langues. J'ai écrit une fois un petit module à la fois Groovy et Robojure. Le programme de clojure avait environ 250 LOC et The Groovy 1000 Loc. Fait intéressant quand j'ai examiné une fonction complexe et l'a écrit de la même manière que c'était exactement le même nombre de lignes. Cela indique que le code groovy était rempli par une plaque de chaudière et m'a donné des raisons supplémentaires de commencer à utiliser le clojure :)
Comme certaines autres personnes ont dit, c'est aussi bon lorsque vous regardez commettant les commits. Si vous avez introduit davantage de lignes de code que vous avez supprimées, vous devez savoir que vous avez accru la complexité de la solution. Cela peut vous faire repenser votre solution si le problème lui-même n'augmente pas la complexité. Cela peut également être une bonne affaire à faire avec vous-même pour encourager le refactoring que si vous ajoutez plus de lignes de code, vous devriez passer un peu de temps à refactoriser.
Enfin, bien que vous puissiez écrire quelque chose difficile à lire en essayant trop de réduire le LOC, une solution avec moins de LOC est presque toujours plus facile à lire car il est tout simplement moins à lire.
Les lignes de code ne sont pas une métrique utile pour comparer différents projets.
Cependant, il peut être utile dans un projet comme figurine en mouvement, permettant de regarder la taille de la base de code qui change au fil du temps. Si vous génèverez un graphique dans le cadre de votre processus CI montrant les lignes de code à chaque construction, cela vous aidera à visualiser comment le projet évolue.
Même dans ce contexte, je dirais que les "lignes de code" exactes, la figure elle-même est sans importance; Ce qui est utile, c'est la visualisation de la tendance - la montée régulière vers le haut, car davantage de fonctionnalités sont ajoutées; les sauts où les grands projets sont terminés; les trempettes où un peu de code redondant a été retiré.
Ceci est utilisé si souvent lors de présentations de vente. Par exemple, KLOC (kilo lignes de code) ou LOC est utilisé pour démontrer le type de compétence que l'organisation du fournisseur dispose des systèmes volumineux/complexes. Cela est particulièrement vrai lorsque le fournisseur tente de mettre en valeur leur capacité à maintenir des systèmes existants existants. Dans le cadre de la négociation, parfois, l'organisation client fournit une partie du code représentative pour exécuter une preuve de concept avec le fournisseur de tester la capacité du vendeur. Ce code de représentation aura suffisamment de complexités pour la société fournisseur à gérer et à maintenir son terrain de vente " Les systèmes avec plusieurs millions de LOC "peuvent venir sous le radar.
Donc, oui, les lignes de code sont utilisées et abusées lors de présentations de vente et, partant, une métrique utile en vente.
Les lignes du code dépendent de la langue.
Par exemple, une ligne de code C vaut une moyenne de X lignes de code ASM. 1 ligne de C++ -> C etc ....
Java et C # encapsulent un peu de lignes de code en raison du support d'arrière-plan du VM.
Le nombre de codes ajoutés pour une tâche donnée dépend en grande partie de qui écrit le code. Il ne devrait pas être utilisé comme mesure de la productivité. Une personne donnée peut produire 1000 lignes de merde redondante et compliquée tandis que le même problème pourrait être résolu par une autre personne dans 10 lignes de code concises. Lorsque vous essayez d'utiliser LOC ajouté en tant que métrique, le facteur "OMS" doit également être pris en compte.
Une métrique réellement utile serait "le nombre de défauts trouvés contre le nombre de lignes ajoutées". Cela vous donnerait une indication des capacités de codage et de couverture de test d'une équipe ou d'une personne donnée.
Comme d'autres ont également signalé, LOC supprimé a de meilleurs droits de vaincre que LOC ajouté :)
Ceci est principalement un ajout au commentaire déjà volumneux. Mais fondamentalement, des lignes de code (ou peut-être totalcharactercount/60) indiquent la taille du monstre. Comme quelques personnes ont dit, cela donne une idée d'une complexité de CodeBase. Son niveau de complexité a beaucoup d'impact. En partie, cela a une incidence sur la difficulté de comprendre le système et de faire un changement.
C'est pourquoi les gens veulent moins de lignes de code. En théorie, moins de lignes de code est moins complexe et il y a moins de place pour l'erreur. Je ne suis pas sûr que savoir que l'avene est terriblement utile pour autre chose que d'estimation et de planification.
Par exemple: supposé que j'ai un projet et sur un examen superficiel, je me rends compte que la question impliquera de modifier jusqu'à 1 000 lignes de code dans une application comportant 10 000 lignes. Je sais que ce projet devrait prendre plus de temps à mettre en œuvre, être moins stable et prend plus de temps à déboguer et à tester.
Il est également extrêmement utile de comprendre la portée du changement entre deux bâtiments. J'ai écrit un petit programme qui analysera la portée du changement entre deux révisions SVN. Il examinera une diffamation unifiée, et de cela, de savoir combien de lignes ont été ajoutées, supprimées ou modifiées. Cela m'aide à savoir à quoi s'attendre dans les tests et les QA qui suit une nouvelle construction. Fondamentalement, un grand nombre de changements signifie que nous devons regarder qui construisent plus près, le mettre à travers des tests de régression complète, etc.
Les limites de comptes de code sont utiles lors de la lancée de l'extension de votre produit complet à un client qui considère les lignes de code pour constituer un indicateur général de la taille du produit. Par exemple, lorsque vous essayez de convaincre une personne, votre produit gère de nombreux cas de coin, ou lorsque vous essayez d'entrer dans une version bêta pour un outil de développement où le fournisseur de l'outil souhaite obtenir une couverture maximale de code à des fins de test.
Le nombre de LOC est utile lors du calcul du taux de défaut (bugs par 1 000 loc, etc.)
Ils peuvent être utiles pour indiquer la magnitude d'une application - ne dit rien sur la qualité! Mon point ici est juste que si vous indiquez que vous avez travaillé sur une application avec 1 000 lignes et que vous disposez d'une application de 500 000 lignes (à peu près), un employeur potentiel peut comprendre si vous avez une expérience de grande taille par rapport à la programmation d'utilité.
Je suis entièrement d'accord avec Warren que le nombre de lignes de code que vous supprimez d'un système est plus utile que les lignes que vous ajoutez.
Toujours. Bunch o'rookies sur cette question. Masters Ecrire un code prolifiquement et densément. De bons grades écrivent beaucoup de lignes mais trop de peluche. Crappers Copier des lignes de code. Donc, d'abord faire une analyse ou une porte de tuiles, bien sûr.
LOC doit être utilisé si votre org ne fait aucun point de complexité, de points de fonction/points de fonction, de commettre ou d'une autre analyse.
Tout développeur qui vous dit de ne pas le mesurer par Loc est shite. Tout maître manivelle code notre comme vous ne croyez pas. J'ai travaillé avec une poignée de 20x à 200 fois plus productive que le programmeur moyen. Et leur code est très, très, très compact et efficace. Oui, comme Djystra, ils ont d'énormes modèles mentaux.
Enfin, dans toute entreprise, la plupart des gens ne leur sont pas bons et la plupart le font, ce n'est pas génial. La programmation n'est pas différente.
Oui, faites une analyse de frappe sur tout projet important et découvrez 20% plus est du code mort. Encore une fois, les programmeurs principaux annihilent régulièrement du code mort et de la Crapcode.