Le décompte LOC doit-il inclure des tests et des commentaires?

Question

Alors que LOC (# lignes de code) est une mesure problématique de la complexité d’un code, il s’agit de la plus répandue et, utilisé avec beaucoup de précaution, peut fournir une estimation approximative de la complexité au moins relative des bases de code (c’est-à-dire programme est 10KLOC et un autre est 100KLOC, écrit dans le même langage, par des équipes partageant à peu près les mêmes compétences, le second programme est presque certainement beaucoup plus complexe).

Lorsque vous comptez les lignes de code, préférez-vous compter les commentaires dans? Qu'en est-il des tests?

J'ai vu différentes approches à ce sujet. Des outils tels que cloc et sloccount permettent d'inclure ou d'exclure des commentaires. D'autres personnes considèrent que les commentaires font partie du code et de sa complexité.

Le même dilemme existe pour les tests unitaires, qui peuvent parfois atteindre la taille du code testé et même le dépasser.

J'ai vu des approches sur tout le spectre, en comptant seulement "opérationnel". lignes non vierges non commentées, vers "XXX lignes de code testé et commenté", ce qui ressemble plus à l'exécution de "wc -l sur tous les fichiers de code du projet".

Quelles sont vos préférences personnelles et pourquoi?

Answer 1

Un homme sage m'a dit un jour "vous obtenez ce que vous mesurez" en matière de gestion de programmeurs.

Si vous les notez dans leur sortie LOC, vous obtenez généralement beaucoup de lignes de code.

Si vous les notez en fonction du nombre de bugs qu’ils résolvent, vous aurez beaucoup de bugs corrigés.

Si vous les notez sur les fonctionnalités ajoutées, vous en obtenez beaucoup.

Si vous les notez sur la complexité cyclomatique, vous obtenez des fonctions ridiculement simples.

Puisque l’un des problèmes majeurs avec les bases de code de nos jours est la rapidité avec laquelle ils grandissent et la difficulté qu’ils ont à changer une fois qu’ils ont grandi, j’ai tendance à hésiter à utiliser le LOC comme métrique, parce que cela mauvais comportement fondamental.

Cela dit, si vous devez l’utiliser, comptez sans commentaires ni tests et exigez un style de codage cohérent.

Mais si vous voulez vraiment une mesure de la "taille du code", il suffit de tar.gz la base de code. Cela a tendance à servir de meilleure estimation approximative du "contenu" que de compter les lignes qui sont sensibles à différents styles de programmation.

Answer 2

Les tests et les commentaires doivent également être conservés. Si vous utilisez LOC comme une métrique (et je suppose que je ne peux pas vous en écarter), vous devez donner les trois (lignes de code réel, commentaires, tests).

La chose la plus importante (et espérons-le évidente) est que vous soyez cohérent. Ne signalez pas un projet avec uniquement les lignes de code réel et un autre avec les trois combinés. Recherchez ou créez un outil qui automatisera ce processus pour vous et générera un rapport.

Lines of Code:       75,000
Lines of Comments:   10,000
Lines of Tests:      15,000
                  ---------
Total:              100,000

De cette façon, vous pouvez être sûr que ce sera le cas

1. Soyez fait.
2. Faites-vous de la même manière à chaque fois.

Answer 3

Personnellement, j'estime que la métrique LOC n'est pas aussi utile que certaines métriques du code.

NDepend vous donnera la métrique LOC mais vous en donnera beaucoup d'autres, telle la complexité cyclométrique. Plutôt que de toutes les énumérer, voici le lien vers la liste.

Il existe également un complément CodeMetric gratuit pour Réflecteur

Answer 4

Je ne vais pas répondre directement à votre question pour une raison simple: je déteste les lignes de métrique du code. Quoi que vous essayiez de mesurer, il est très difficile de faire pire que LOC; Pratiquement toute autre métrique à laquelle vous voudrez penser sera meilleure.

En particulier, vous semblez vouloir mesurer la complexité de votre code. Dans l’ensemble, la complexité cyclométrique (également appelée complexité de McCabe) est bien meilleure métrique à cet égard.

Les routines avec une complexité cyclométrique élevée sont celles sur lesquelles vous souhaitez concentrer votre attention. Ce sont ces routines qui sont difficiles à tester, pourries au coeur avec des bugs et difficiles à maintenir.

De nombreux outils mesurent ce type de complexité. Une recherche rapide sur Google dans votre langue préférée vous permettra de trouver des dizaines d’outils qui font ce genre de complexité.

Answer 5

Lignes de code signifie exactement cela: aucun commentaire ni aucune ligne vide ne sont comptés. Et pour qu'il soit comparable à un autre code source (que la métrique soit utile ou non, vous avez besoin d'au moins des styles de codage similaires:

for (int i = 0; i < list.count; i++)
{
    // do some stuff
}

for (int i = 0; i < list.count; i++){
    // do some stuff
}

La deuxième version fait exactement la même chose, mais a un LOC de moins. Lorsque vous avez beaucoup de boucles imbriquées, cela peut résumer un peu. C’est pourquoi des métriques telles que points de fonction ont été inventées.

Answer 6

Cela dépend de l'utilisation que vous faites du LOC.

En tant que mesure de la complexité - pas tellement. Peut-être que 100KLOC sont pour la plupart du code généré à partir d’une simple table, et les expressions rationnelles kas 5KLOC de 10KLOC.

Cependant, chaque ligne de code associée à un coût de fonctionnement est visible. Vous payez pour chaque ligne tant que le programme vit: il doit être lu lorsqu'il est maintenu, il peut contenir une erreur qui doit être corrigée, il augmente le temps de compilation, le contrôle du contrôle de la source et les temps de sauvegarde, avant de changer. ou supprimez-le, vous devrez peut-être vérifier si quelqu'un s'y fie, etc. Le coût moyen peut être de nanopennies par ligne et par jour, mais c'est tout ce qui compte.

KLOC peut être un indicateur immédiat du besoin en infrastructure d’un projet. Dans ce cas, j'inclurais des commentaires et des tests, même si le coût d'exploitation d'une ligne de commentaire est bien inférieur à celui d'une expression rationnelle du deuxième projet.

[modifier] [une personne ayant un avis similaire sur la taille du code] 1

Answer 7

Nous utilisons uniquement une métrique de lignes de code pour une chose - une fonction devrait contenir assez peu de lignes de code pour être lues sans faire défiler l'écran. Les fonctions plus importantes sont généralement difficiles à lire, même si leur complexité cyclométrique est très faible. Pour son utilisation, nous comptons les espaces et les commentaires.

Il peut également être intéressant de voir le nombre de lignes de code que vous avez supprimées au cours d'un refactor. Dans ce cas, vous souhaitez uniquement compter les lignes de code réelles, les espaces blancs qui ne facilitent pas la lecture et les commentaires. qui ne sont pas utiles (qui ne peuvent pas être automatisés).

Enfin, un disclaimer - utilisez les métriques de manière intelligente. Une bonne utilisation des métriques est d'aider à répondre à la question "quelle partie du code bénéficierait le plus du refactoring" ou "quelle est l'urgence d'une révision du code pour la dernière extraction?" - une fonction sur 1000 lignes avec une complexité cyclomatique de 50 correspond à une enseigne au néon clignotante indiquant «refactor me now». Une mauvaise utilisation des métriques est "quelle est la productivité du programmeur X" ou "La complexité de mon logiciel" .

Answer 8

Extrait de l'article: Comment comptez-vous votre nombre de lignes de code (LOC)? par rapport à l'outil NDepend qui compte le logique nombre de lignes de code pour les programmes .NET.

Comment comptez-vous votre nombre de lignes de code (LOC)?

Comptez-vous la déclaration de signature de méthode? Comptez-vous des lignes avec seulement un crochet? Comptez-vous plusieurs lignes lorsqu'un seul appel de méthode est écrit sur plusieurs lignes en raison d'un nombre élevé de paramètres? Comptez-vous les & # 8216; espaces de noms & # 8217; et & # 8216; utilisation de l'espace de noms & # 8217; déclaration? Comptez-vous la déclaration des méthodes d'interface et abstraites? Comptez-vous l'attribution de champs quand ils sont déclarés? Comptez-vous la ligne blanche?

En fonction du style de codage de chaque développeur et du langage choisi (C #, VB.NET & # 8230;), une différence significative peut être constatée en mesurant le LOC.

Apparemment, mesurer le LOC à partir d’une analyse de fichiers source ressemble à un sujet complexe. Grâce à un astucieux, il existe un moyen simple de mesurer exactement ce que l’on appelle le LOC logique. Le LOC logique présente deux avantages significatifs par rapport au LOC physique (le LOC déduit de l'analyse des fichiers source):

• Le style de codage n’interfère pas avec le LOC logique. Par exemple, le LOC ne changera pas car un appel de méthode est généré sur plusieurs lignes en raison du nombre élevé d’arguments.
• Le LOC logique est indépendant de la langue. Les valeurs obtenues à partir d'assemblées écrites dans différentes langues sont comparables et peuvent être additionnées.

Dans le monde .NET, le LOC logique peut être calculé à partir des fichiers PDB, les fichiers utilisés par le débogueur pour lier le code IL au code source. L'outil NDepend calcule le LOC logique d'une méthode de la manière suivante: il est égal au nombre de points de séquence trouvé pour une méthode dans le fichier PDB. Un point de séquence est utilisé pour marquer un point dans le code IL qui correspond à un emplacement spécifique dans la source d'origine. Plus d'informations sur les points de séquence ici. Notez que les points de séquence correspondant aux accolades en C # & # 8216; {& # 8216; et & # 8216;} & # 8217; ne sont pas pris en compte.

De toute évidence, le LOC d’un type correspond à la somme de ses méthodes & # 8217; LOC, le LOC d’un espace de noms correspond à la somme de ses types & # 8217; LOC, le LOC d’un assemblage est la somme de ses espaces de noms & # 8217; LOC et le LOC pour une application est la somme de ses assemblages LOC. Voici quelques observations:

• Les interfaces, les méthodes abstraites et les énumérations ont un LOC égal à 0. Seul le code concret effectivement exécuté est pris en compte lors du calcul du LOC.
• Les déclarations d'espaces de nommage, de types, de champs et de méthodes ne sont pas considérées comme des lignes de code car elles n'ont pas de points de séquence correspondants.
• Lorsque le compilateur C # ou VB.NET est confronté à une initialisation de champs d'instance en ligne, il génère un point de séquence pour chaque constructeur d'instance (la même remarque s'applique à l'initialisation de champs statiques en ligne et au constructeur statique).
• La LOC calculée à partir d’une méthode anonyme n’interfère pas avec la LOC de ses méthodes de déclaration externes.
• Le rapport global entre NbILInstructions et LOC (en C # et VB.NET) est généralement d’environ 7.