LOC est probablement l'une des mesures les plus utilisées, et en conséquence est probablement l'une des mesures les plus inutiles de la qualité du code et une mesure encore plus inutile de l'effort de programmation.
Oui, c'est une déclaration audacieuse pour moi de faire, et non, je ne peux pas vous indiquer des études prouvant mon point. Cependant, je peux affirmer avec une expérience durement acquise que lorsque vous commencez à vous soucier de la quantité de code que vous avez écrit, vous vous inquiétez probablement des mauvais problèmes.
Vous devez d'abord vous demander ce que vous essayez de mesurer ou de prouver, et si cette preuve est simplement hors d'intérêt, ou pour soutenir une amélioration de la qualité plus large et où vous devez utiliser ces informations pour obtenir l'adhésion de votre équipe. / la direction pour faire quelque chose.
L'une des choses pour lesquelles j'ai tendance à utiliser LOC est un peu de santé mentale. Si je me retrouve à écrire beaucoup de code, je m'intéresse davantage au LOC par méthode, ou au LOC par classe, plutôt qu'au LOC dans l'ensemble. Ces mesures peuvent être des indicateurs que vous devez refactoriser davantage si vous vous sentez un petit trouble obsessionnel-compulsif sur la façon dont votre code devrait être factorisé. Les classes très volumineuses peuvent avoir besoin d'être refactorisées en quelques classes plus petites, et les longues méthodes multilignes peuvent devoir être décomposées en plusieurs méthodes, d'autres classes, ou peuvent même indiquer une répétition qui pourrait être supprimée. Remarquez que j'ai utilisé le mot «pourrait» plusieurs fois là-bas.
La réalité est que LOC ne fournit qu'un indicateur possible et aucune garantie réelle que votre code puisse avoir besoin de changer. La vraie question à se poser est de savoir si le code se comporte comme requis et comme prévu. Si c'est le cas, votre prochaine question est de savoir si vous serez en mesure de maintenir le code facilement et si vous aurez le temps, maintenant ou à l'avenir, d'apporter des modifications au code de travail pour réduire vos frais de maintenance à l'avenir.
Souvent, beaucoup de code signifie que vous aurez plus à gérer plus tard, mais parfois même un code bien factorisé peut s'étendre sur des centaines de lignes de code, et oui, vous pouvez parfois vous retrouver à écrire des centaines de lignes de code en une journée. L'expérience me dit cependant que si je soutiens une sortie de centaines de lignes de nouveau code chaque jour, il y a souvent un risque qu'une grande partie du code soit copiée et collée de manière inappropriée ailleurs, et cela en soi peut indiquer des problèmes avec la duplication et la maintenance, mais là encore ce n'est pas une garantie, j'ai donc tendance à compter sur ce que mon expérience et mon instinct me disent en fonction de la façon dont les tâches à accomplir ont été accomplies.
La meilleure façon d'éviter le dilemme posé dans votre question à mon humble avis est d'oublier le LOC et de refaçonner TOUT le temps. Écrivez d'abord votre test de code, implémentez pour échouer, refactorisez pour passer, puis voyez ce qui peut être refactorisé et ensuite améliorez le code. Vous quitterez la tâche en sachant que vous avez déjà revérifié votre travail, et vous ne serez pas si inquiet à l'idée de vous remettre en question à l'avenir. De manière réaliste, si vous utilisez une approche de test d'abord comme je l'ai décrit, toute mesure LOC / jour sur votre code terminé signifie vraiment que vous avez écrit 3 à 5 fois la quantité mesurée, cet effort étant masqué avec succès par votre refactoring en cours efforts.