A quel point le SLOC (source lines of code) est-il mauvais en tant que métrique? [fermé]

Quelqu'un a dit :

"utiliser le SLOC pour mesurer les progrès du logiciel, c'est comme utiliser le kg pour mesurer les progrès de la fabrication d'aéronefs"

Il est totalement inapproprié, car il encourage les mauvaises pratiques de la forme :

• Syndrome Du Copier-Coller

• décourager le remaniement pour rendre les choses plus faciles

• farce sans signification les commentaires

• ...

La seule utilisation est qu'il peut vous aider à estimer la quantité de papier à mettre dans l'imprimante lorsque vous effectuez une copie imprimée de la source complète de l'arbre.

le problème avec SLOC est que C'est une métrique facile à utiliser. Être productif ne signifie pas produire plus de code. Donc la façon dont je l'ai expliqué aux gens baring ce que Skilldrick a dit est ceci:

1. plus il y a de lignes de code, plus quelque chose devient compliqué.
2. plus quelque chose devient compliqué, plus il est difficile de le comprendre.
3. avant d'ajouter une nouvelle fonctionnalité ou de corriger un bogue, j'ai besoin de la comprendre.
4. Compréhension prend du temps.
5. le Temps coûte de l'argent.

Petit code -> plus facile à comprendre -> moins cher d'ajouter de nouvelles fonctionnalités

les compteurs de haricots peuvent comprendre cela.

Montrer la différence entre:

for(int i = 0; i < 10; i++) {
    print i;
}

et

print 0;
print 1;
print 2;
...
print 9

et demandez-leur SI 10 SLOC ou 3 SLOC est mieux.

En réponse aux commentaires:

1. Il ne faut pas longtemps pour expliquer comment un for la boucle fonctionne.

2. Après vous les montrer, disons "nous devons maintenant écrire les nombres jusqu'à 100 - voici comment effectuer le changement."et montrer combien de temps il faut pour changer le code non sec.

Je ne suis pas d'accord sur le fait que le SLOC soit une mauvaise métrique. Il peut être discutable d'entrer dans une question vieille de plusieurs années avec onze réponses, mais je vais quand même en ajouter une autre.

la plupart des arguments l'appellent une mauvaise métrique parce qu'elle n'est pas adaptée pour mesurer directement productivité. C'est un argument étrange; il suppose que la métrique doit être utilisée d'une manière insensée. Avec ce raisonnement, on pourrait appeler le Kelvin une mauvaise unité parce qu'il n'est pas adapté pour mesurer la distance.

la longueur du Code est une solution viable mesure de ballast.

La quantité de non-commenter les lignes de code en corrélation avec:

• des erreurs non détectées
• frais d'entretien
• temps de formation pour les nouveaux contributeurs
• frais de migration
• coûts des nouvelles fonctionnalités

et beaucoup d'autres types de coûts similaires, comme le coût de l'optimisation.

bien sûr, le nombre de SLOC n'est pas une mesure précise de tout cela. Le Code peut être n'importe où entre très agréable et très laid à gérer. Mais on peut supposer que la longueur du code est rarement libre, et donc, le code plus long est souvent plus difficile à gérer.

si je gérais une équipe de programmeurs, je voudrais vraiment garder une trace du ballast qu'il crée ou enlève.

Assez mauvais (-:

une bien meilleure idée serait de couvrir les cas d'essai, plutôt que le code.

l'idée est La suivante: développeur de commettre un cas de test qui échoue, puis valider le correctif dans la prochaine génération, et les cas de test doit passer ... il suffit de mesurer combien de cas de test le développeur a ajouté.

en bonus collecter les statistiques de couverture (la couverture par branche est meilleure que la couverture par ligne ici).

Expliquer que SLOC est une excellente mesure des lignes de code dans l'application, rien d'autre.



le nombre de lignes dans un livre, ou la longueur d'un film, ne détermine pas sa qualité. Vous pouvez améliorer un film et le raccourcir, vous pouvez améliorer une application et réduire les lignes de code.

vous ne jugez pas de la qualité(combien de fonctionnalités,comment il fonctionne)..) un plan est basé sur son poids(sloc).

quand vous voulez que votre avion vole plus haut, plus longtemps et mieux, vous n'y ajoutez pas de poids. Remplacer les pièces avec briquet/les meilleurs matériaux. Vous enlevez les pièces dont vous n'avez pas besoin pour ne pas ajouter de poids inutile.

je crois que SLOC est une bonne métrique. Il vous indique la taille de votre système. C'est bon pour juger de la complexité et des ressources. Et il vous aide à préparer le prochain développeur pour travailler sur une base de code.

mais le nombre de SLOC ne doit être analysé qu'après l'application d'autres mesures appropriées de la qualité du code. Si...

• N'écrivez pas 2 lignes de code quand 1 le fera, à moins que les 2 lignes version rend le code 2 fois plus facile à maintenir.
• ne pas code fluff avec des commentaires inutiles juste pour compter les SLOC fluff.
• ne payez pas les gens selon le nombre de SLOC.

je gère des projets logiciels depuis 30 ans. J'utilise SLOC count tout le temps, pour aider à comprendre les systèmes Matures. Je n'ai jamais trouvé utile de même jeter un coup d'oeil sur le nombre de SLOC jusqu'à ce qu'un projet soit proche de la version 1.0.

fondamentalement, au cours du processus de développement, je m'inquiète de la qualité, de la performance, de l'utilisabilité et de la conformité à spécification. Obtenir ces droit, et le projet sera probablement un succès. Quand la poussière retombe, regardez le nombre de SLOC. Vous pourriez être surpris que vous ayez obtenu autant de 5000 lignes de code. Et tu pourrais être surpris que tu aies eu si peu! (Mais le nombre de SLOC n'a pas d'incidence sur la qualité, le rendement, la convivialité et la conformité aux spécifications.)

et toujours coder comme la personne qui va travailler sur votre code suivant est un psychopathe violent qui sait où vous vivre.

Cheers, Oncle Puce

même les outils de métrique de code modernes critiquent le SLOC conting, j'aime le point fait dans la FAQ ProjectCodeMeter:

Qu'y a-t-il de mal à compter les lignes de Code (SLOC / LLOC)?

Pourquoi SLOC est mauvais un individu métrique de productivité

pensez au code comme un bloc d'argile/pierre. Il faut découper, disons 10 statues. Ce n'est pas le nombre de statues que tu sculptes qui compte. C'est à quel point tu l'as sculpté qui compte. De même, ce n'est pas le nombre de lignes que vous avez écrites, mais leur fonctionnement. En cas de code LOC peut se retourner contre une métrique de cette façon.

la productivité change aussi lors de l'écriture d'un code complexe. Il faut un deuxième pour écrire une déclaration d'impression, mais beaucoup de temps pour écrire un morceau complexe de logique. Pas tous les doigts sont égaux.

comment utiliser le SLOC à votre avantage

je pense que SLOC pour défaut % est une bonne mesure. Oui, le niveau de difficulté entre en jeu, mais c'est un bon paramètre que les gestionnaires peuvent contourner en faisant des affaires. Essayez de penser de leur point de vue aussi. Ils ne vous détestent ni vous ni votre travail, mais ils doivent dire aux clients que vous êtes le meilleurs et pour cela ils ont besoin de quelque chose de tangible. Donnez-leur ce que vous pouvez :)

SLOC peut être modifié de façon spectaculaire en ajoutant des lignes vides ("pour la lisibilité") ou en mettant ou en supprimant des commentaires. Ainsi, le fait de ne compter que sur le SLOC peut conduire à la confusion.

pourquoi ne comprennent-ils pas que le SLOC n'a pas changé, mais le logiciel fait plus que ce qu'il a fait hier parce que vous avez ajouté de nouvelles fonctionnalités, ou corriger des bogues?

maintenant, expliquez - leur comme ceci. Mesurer combien de travail a été fait dans votre code en comparant les lignes de code est la même chose que de mesurer combien de traits sont dans votre téléphone cellulaire le comparant par la taille. Les téléphones cellulaires ont diminué en taille sur 20 ans, tout en ajoutant plus de fonctionnalités en raison des améliorations technologiques et techniques. Un bon code suit ce même principe car nous pouvons exprimer la même logique en de moins en moins de lignes de code, ce qui le rend plus rapide à exécuter, plus facile à maintenir, et plus simple à comprendre que nous améliorons notre compréhension du problème et introduisons de nouvelles techniques pour le développement.

je voudrais les amener à se concentrer sur la valeur d'affaires retourné par le développement de la fonctionnalité, la maintenance, et les corrections de bug. Si celui qui est heureux avec le logiciel dit qu'ils peuvent voir l'amélioration ne transpire pas la ligne de codage.

Aller lire ceci:

https://stackoverflow.com/questions/3800707/what-is-negative-code