Quelle est la fascination avec les mesures de code? [fermé]

Question

Quelle est la fascination avec les mesures de code? [fermé]

ces derniers temps, j'ai vu un certain nombre de questions liées au "Code metrics", et je dois me demander ce qu'est la fascination? Voici quelques exemples récents:

dans mon esprit, aucune métrique ne peut remplacer une révision du code, bien que:

certaines mesures peuvent parfois indiquer des endroits qui doivent être revus, et
des changements radicaux dans les paramètres sur de courtes périodes peuvent indiquer des endroits qui doivent être revus

mais je ne peux pas penser à une seule métrique qui par elle - même indique toujours " bon " ou "mauvais" code-il ya toujours des exceptions et des raisons pour les choses qui les mesures ne peuvent pas voir.

est-ce qu'il y a des idées magiques à tirer des mesures de code que j'ai négligées? Les programmeurs/gestionnaires paresseux cherchent-ils des excuses pour ne pas lire le code? Est-ce que les gens sont présentés avec des bases de code d'héritage géantes et à la recherche d'un endroit pour commencer? Ce qui se passe?

Note: j'ai posé certaines de ces questions sur les fils spécifiques à la fois dans les réponses et les commentaires et n'a obtenu aucune réponse, donc j'ai pensé que je devrais demander à la communauté en général que peut-être je passe à côté de quelque chose. Il serait agréable d'exécuter un travail de fournée de mesures et de ne pas réellement avoir à lire le code d'autres personnes (ou le mien) jamais plus, Je ne pense pas que ce soit pratique!

EDIT: je suis familier avec la plupart, si pas tous les paramètres discutés, Je ne vois pas l'intérêt de les considérer isolément ou comme des standards de qualité arbitraires.

81

code-metrics

demandé sur Scath 2008-10-12 23:23:37

18 réponses

j'ai eu un projet que j'ai fait comme un travail d'une personne mesurée pour la complexité cyclomatique Il ya quelques mois. C'était ma première exposition à ce genre de mesures.

le premier rapport que j'ai reçu était choquant. Presque toutes mes fonctions ont échoué au test, même les (imho) très simples. J'ai contourné le problème de la complexité en déplaçant la sous-tâche logique dans les sous-programmes, même s'ils n'ont été appelés qu'une seule fois.

Pour l'autre moitié des routines ma fierté comme un programmeur a commencé et j'ai essayé de les réécrire d'une manière qu'ils font la même chose, juste plus simple et plus lisible. Cela a fonctionné et j'ai été en mesure d'obtenir le plus bas pour les clients yclomatic seuil de complexité.

finalement, j'ai presque toujours pu trouver une meilleure solution et un code beaucoup plus propre. La performance n'a pas souffert de cela (croyez - moi-je suis paranoïaque à ce sujet, et je vérifie le démontage de la sortie du compilateur assez souvent).

je pense que les mesures sont une bonne chose si vous les utilisez comme raison/motivation pour améliorer votre code. Il est important de savoir quand s'arrêter et de demander une subvention de violation métrique.

les mesures sont des guides et des aides, pas des fins en soi.

21

répondu Nils Pipenbrinck 2008-10-12 19:51:39

la meilleure métrique que j'ai jamais utilisée est le score C. R. A. P. http://www.artima.com/weblogs/viewpost.jsp?thread=215899

essentiellement, c'est un algorithme qui compare la complexité cyclomatique pondérée avec la couverture de test automatique. L'algorithme ressemble à ceci: CRAP(m) = comp(m)^2 * (1 – cov(m)/100)^3 + comp(m) où comp(m) est la complexité cyclomatique de la méthode m, et cov (m) est la couverture du code d'essai fournie par les tests automatisés.

les auteurs de l'article ci-dessus mentionné (s'il vous plaît, allez le lire...ça vaut bien votre temps) suggérez un score maximum de 30 C. R. A. P. qui se décompose de la façon suivante:

Method’s Cyclomatic Complexity % of coverage required to be below CRAPpy threshold ------------------------------ -------------------------------- 0 – 5 0% 10 42% 15 57% 20 71% 25 80% 30 100% 31+ No amount of testing will keep methods this complex out of CRAP territory.

comme vous le voyez rapidement, le code d'écriture métrique récompense qui n'est pas complexe couplé avec une bonne couverture des tests (si vous écrivez des tests unitaires, et vous devriez l'être, et ne mesurez pas la couverture...Eh bien, vous apprécieriez probablement cracher dans le vent ainsi). ;- )

Pour la plupart de mes équipes de développement j'ai vraiment essayé d'obtenir la note C. R. A. P. en dessous de 8, mais s'ils avaient des raisons valables pour justifier la complexité supplémentaire qui était acceptable tant qu'ils ont couvert la complexité avec suffisamment de tests. (L'écriture de code complexe est toujours très difficile à tester...une sorte d'avantage caché de cette métrique).

la plupart des gens ont eu du mal au départ à écrire un code qui leur permettrait de passer le score C. R. A. P. Mais avec le temps, ils ont écrit un meilleur code, un code qui avait moins de problèmes, et le code était plus facile à déboguer. De toute métrique, c'est celui qui a le moins de préoccupations et le plus grand avantage.

13

répondu RMatthews 2010-07-27 17:06:02

pour moi la métrique la plus importante qui identifie le mauvais code est la complexité cyclomatique. Presque toutes les méthodes dans mes projets sont en dessous de CC 10 et les bogues sont invariablement trouvés dans les méthodes héritées avec CC plus de 30. Haut CC indique habituellement:

code écrit en hâte (ie. il n'y avait pas de temps pour trouver une solution élégante et non pas parce que le problème nécessitait une solution complexe)

code non testé (personne n'écrit des tests pour de telles bêtes)

code qui a été corrigé et corrigé à de nombreuses reprises (c.-à-d. criblé avec les fi et les commentaires todo)

une cible de choix pour la refactorisation

9

répondu Goran 2008-10-12 21:36:57

une bonne révision du code ne remplace pas un bon outil d'analyse statique, qui ne remplace évidemment pas une bonne série d'essais unitaires, maintenant les essais unitaires ne sont pas bons sans une série d'essais de réception......

les mesures de Code sont un autre outil à mettre dans votre boîte à outils, ils ne sont pas une solution en soi ils sont juste un outil à utiliser comme approprié (avec bien sûr tous les autres outils dans votre boîte!).

8

répondu Scott James 2008-10-12 19:42:15

mon opinion très subjective est que les mesures de code expriment la fascination institutionnelle irrésistible d'être en mesure de quantifier quelque chose d'intrinsèquement non quantifiable.

a un sens, d'une certaine manière, au moins psychologiquement - comment prendre des décisions sur quelque chose que vous ne pouvez pas évaluer ou comprendre? En fin de compte, bien sûr, vous ne pouvez pas évaluer la qualité à moins que vous êtes bien informé sur le sujet (et sont au moins aussi bons que ce que vous essayez d'évaluer) ou demandez à quelqu'un de bien informé, ce qui, bien sûr, remet le problème en question.

en ce sens, peut-être qu'une analogie raisonnable serait d'évaluer les étudiants par les résultats au SAT, c'est injuste et manque toutes sortes de subtilité, mais si vous avez besoin de quantifier, vous devez faire quelque chose.

ne pas dire que je pense que c'est une bonne mesure, seulement que je peux voir l'irrésistibilité constitutionnelle de lui. Et, comme vous l'avez souligné, il y a probablement quelques métrique (beaucoup de 500+ méthodes de ligne , haute complexité-probablement mauvais). Je n'ai jamais été à un endroit qui a acheté ça,cependant.

6

répondu Steve B. 2008-10-12 19:31:50

il y a un code métrique en lequel je crois.

je travaille sur un gros système. Quand une seule nouvelle exigence m'est venue, je me suis mis à la coder. Quand j'ai fini et que j'ai réglé les bugs, je vérifie dans le système de contrôle de version. Ce système fait une différence, et compte tous les changements que j'ai faits.

plus ce nombre est petit, mieux c'est.

6

répondu Mike Dunlavey 2008-11-22 14:50:37

les gens sont attirés à l'idée de moyens mécanistes pour comprendre et décrire le code. Si c'est vrai, pensez aux ramifications pour l'efficacité et la productivité!

je suis d'accord qu'une métrique pour" la bonté du code "est à peu près aussi sensible qu'une métrique pour" la bonne prose."Cependant, cela ne signifie pas que les mesures sont inutiles, peut-être simplement mal utilisées.

par exemple, valeurs extrêmes pour certaines mesures indiquer le chemin à problèmes possibles. Une méthode longue de 1000 lignes est probablement Impossible à maintenir. Code avec zéro unité code de test couverture probablement a plus de bogues que le code similaire avec beaucoup de tests. Un grand saut dans le code ajouté à un projet juste avant la publication qui n'est pas une bibliothèque de tiers est probablement cause pour l'attention supplémentaire.

je pense que si nous utilisons des mesures comme suggestion -- un drapeau rouge -- peut-être qu'elles peuvent être utiles. Le problème est que les gens commencent à mesurer la productivité en SLOC ou la qualité en pourcentage des lignes avec des tests.

5

répondu Jason Cohen 2008-10-12 19:31:07

les mesures et les tests automatisés ne sont pas censés remplacer les examens complets du code.

ils ont juste accéléré les choses. Avec un vérificateur automatique, il est très facile de voir quelles conventions vous avez oublié de suivre, que vous utilisez les paquets et les méthodes désignés, etc. Vous pouvez voir ce que vous pouvez résoudre sans l'aide d'autres personnes.

les gestionnaires aiment aussi les mesures parce qu'ils ont l'impression d'obtenir un chiffre exact sur la productivité (bien que ce ne soit souvent pas le cas) et ils devraient être en mesure de mieux jongler avec les gens.

5

répondu Oli 2008-10-12 19:31:25

les mesures ne sont utiles que si:

l'équipe les a développés

L'équipe a accepté

Ils sont utilisés pour identifier une zone spécifique

en général, toute métrique qui ne rentre pas dans cela souffrira de l'équipe qui l'optimise. Vous voulez mesurer des lignes de code? Regardez combien ils en écrivent! Vous voulez mesurer la couverture de code, par golly, Regardez-moi couvrez ce code!

je pense que les mesures peuvent être utiles pour identifier les tendances, et en fait, j'en ai vu quelques-unes utiles, comme tracer quand la construction casse, le code churn (nombre de lignes de code changeant tout au long du projet) et d'autres choses. Mais si l'équipe ne vient pas avec eux, ou s'ils ne sont pas d'accord ou ne les comprennent pas, vous êtes probablement dans un monde de souffrance.

5

répondu Cory Foy 2008-10-12 19:32:19

voici quelques mesures de complexité de stan4j(http://stan4j.com/).

Une éclipse structure de classe d'analyser l'outil.

j'aime cet outil et les paramètres. Je traite les mesures comme des statistiques, des indicateurs, des messages d'avertissement. Parfois, en raison de certaines méthodes ou certaines classes a vraiment de logique compliquée fait d'eux complexes, ce qui doit être fait est de garder un œil sur eux, examinez-les pour voir s'il est nécessaire de les remanier ou de les revoir. soigneusement, en raison de Normalement ils sont sujets à des erreurs. Aussi je l'utilise, d'analyser outil pour apprendre le code source, en raison de j'aime apprendre du complexe au simple.En fait il comprend quelques autres statistiques, telles que Robert C. Martin Métriques, Chidamber Et Kemerer Métriques,Comte de Métriques Mais je préfère celui-ci

Métriques De Complexité

Complexité Cyclomatique Mesures

Cyclomatic Complexité (CC) 151980920" La complexité cyclomatique d'une méthode est le nombre de points de décision dans le graphique de flux de contrôle de la méthode incrémenté d'un. Les points de décision se produisent aux énoncés if/for/while, aux clauses case/catch et aux éléments de code source similaires, où le flux de contrôle n'est pas seulement linéaire. Le nombre de points de décision (byte code) introduits par un seul énoncé (source code) peut varier, en fonction par exemple de la complexité des expressions booléennes. Plus la complexité cyclomatique la valeur d'une méthode est, le plus de cas d'essai sont nécessaires pour tester toutes les branches du graphique de flux de contrôle de la méthode.

Complexité Cyclomatique Moyenne Valeur moyenne de la métrique de complexité cyclomatique pour toutes les méthodes d'une application, d'une bibliothèque, d'un arbre de paquets ou d'un paquet.

Fat Mesures La Graisse métrique d'un objet est le nombre d'arêtes dans un graphe de dépendance de l'artefact. Le le type de graphe de dépendance dépend de la variante métrique et de l'artefact choisi:

matières grasses La métrique de Fat d'une application, d'une bibliothèque ou d'un arborescence de paquets est le nombre de bord de son graphique de dépendance sous-arbre. Ce graphique contient tous les enfants de l'artefact dans la hiérarchie de l'arborescence des paquets, y compris les paquets leaf. (Pour voir le graphique approprié dans la vue Composition, la bascule des paquets plats de L'Explorateur de Structure doit être désactivée. spectacle Bibliothèques bascule doit être activé si l'artefact choisi est une bibliothèque, sinon il doit être désactivé.)

la métrique de la graisse d'un paquet est le nombre de bords de son graphique de dépendance unitaire. Ce graphique contient toutes les classes de premier niveau du paquet.

la métrique de la matière grasse d'une classe est le dénombrement des arêtes du Graphe de ses membres. Ce graphique contient tous les champs, méthodes et classes de membres de la classe. (Ce graphique et la valeur de Fat ne sont disponibles que si le code l'analyse a été effectuée avec un membre du niveau de détail, et non avec la classe.)

la Graisse pour les Dépendances de la Bibliothèque (Fat - Bibliothèques) Le Fat pour la métrique des dépendances de bibliothèque d'une application est le nombre de bord de son graphe de dépendance de bibliothèque. Ce graphe contient toutes les bibliothèques de l'application. (Pour voir le graphe approprié dans la vue de Composition, la bascule des bibliothèques D'exposition de L'Explorateur de Structure doit être activée.)

matières grasses pour Dépendance À L'Égard Des Paquets Plats (Fat - Packages) Le Fat pour la métrique des dépendances de paquet plat d'une application est le nombre de bords de son graphique de dépendance de paquet plat. Ce graphique contient tous les paquets de la demande. (Pour voir le graphique approprié dans la vue Composition, la bascule des paquets plats de L'Explorateur de Structure doit être activée et la bascule des bibliothèques D'affichage doit être désactivée.)

le Fat pour les dépendances de paquet plat métrique d'une bibliothèque est le bord compter de son paquet plat graphe de dépendance. Ce graphique contient tous les paquets de la bibliothèque. (Pour voir le graphe approprié dans la vue Composition, les paquets plats de L'Explorateur de Structure et les toggles D'affichage des bibliothèques doivent être activés.)

Gras pour la Classe de Haut Niveau des Dépendances (Fat - Unités) Le Fat pour la métrique des dépendances de classe supérieure d'une application ou d'une bibliothèque est le nombre de bord de son graphique de dépendance d'unité. Ce graphique contient tout le haut les classes de niveau de l'application ou de la bibliothèque. (Pour des applications raisonnables, il est trop grand pour être visualisé et ne peut donc pas être affiché dans la vue de Composition. Les graphiques de dépendance d'unité ne peuvent être affichés que pour les paquets.)

4

répondu Clark Bao 2011-08-18 13:04:30

peut être utile pour déterminer l'amélioration ou la dégradation dans un projet, et peut certainement trouver le style et les violations de la convention, mais il n'y a pas de substitut pour faire des examens par les pairs code. Vous ne pouvez pas connaître la qualité de votre code sans eux.

Oh ... et cela suppose qu'au moins un des participants à votre révision du code a un indice.

2

répondu Steve Moyer 2008-10-12 19:33:00

je suis d'accord avec vous que les mesures de code ne devraient pas remplacer une révision de code, mais je crois qu'elles devraient compléter les révisions de code. Je pense qu'il revient au vieux dicton: "on ne peut pas améliorer ce qu'on ne peut pas mesurer."Les mesures de Code peuvent fournir à l'équipe de développement des "odeurs de code" quantifiables ou des modèles qui peuvent nécessiter un examen plus approfondi. Les paramètres qui sont saisis dans la plupart des outils d'analyse statique sont généralement des paramètres qui ont été identifiés au cours de la recherche dans la courte histoire de notre domaine d'avoir une signification significative.

2

répondu SaaS Developer 2008-10-12 19:37:06

les mesures ne remplacent pas la révision du code, mais elles sont beaucoup moins chères. Ils sont un indicateur plus que tout.

2

répondu Andy Lester 2008-10-12 19:42:57

une partie de la réponse est que certaines mesures de code peuvent vous donner un coup de couteau très rapide et initial à une réponse à la question: à quoi ressemble ce code?

même les 'lignes de code' peuvent vous donner une idée de la taille de la base de code que vous regardez.

comme mentionné dans une autre réponse, l'évolution des mesures vous donne le plus d'informations.

2

répondu quamrana 2008-10-12 21:02:36

les mesures d'elles-mêmes ne sont pas particulièrement intéressantes. C'est ce que l'on en fait qui compte.

par exemple, si vous mesuriez le nombre de commentaires par ligne de code, que considéreriez-vous comme une bonne valeur? Qui sait? Ou peut-être plus important encore, chacun a sa propre opinion.

maintenant si vous collectez assez d'informations pour pouvoir corréler le nombre de commentaires par ligne de code avec le temps nécessaire pour résoudre un bogue ou par rapport au nombre de bogues trouvés qui sont attribués au codage, alors vous pouvez commencer à trouver un nombre empiriquement utile.

il n'y a pas de différence entre l'utilisation de mesures dans un logiciel et l'utilisation de toute autre mesure de performance sur tout autre processus - d'abord vous mesurez, puis vous analysez, puis vous améliorez le processus. Si tu ne fais que mesurer, tu perds ton temps.

edit: En réponse à Steven A. Lowe commentaires - qui est absolument correct. Dans toute analyse de données, il faut veiller à distinguer entre une relation causale et une simple corrélation. Et le choix des paramètres sur la base de l'adéquation est important. Il est inutile d'essayer de mesurer la consommation de café et d'attribuer la qualité du code (même si je suis sûr que certains ont essayé ;-) )

mais avant que vous puissiez trouver la relation (causale ou non) vous devez avoir les données.

La sélection des données à collecter est basé sur ce processus vous souhaitez vérifier ou améliorer. Par exemple, si vous essayez d'analyser le succès de vos procédures de révision de code (en utilisant votre propre définition de "succès", que ce soit la réduction des bogues ou des bogues de codage, ou des délais d'exécution plus courts ou autre), alors vous sélectionnez des mesures qui mesurent le taux total de bogues et le taux de bogues dans le code révisé.

donc avant de collecter les données, vous devez savoir ce que vous voulez en faire. Si la métrique est le moyen, qu'est-ce que la fin?

2

répondu Andrew Edgecombe 2008-10-13 06:43:45

Je ne pense pas que de petits changements dans les paramètres soient significatifs: une fonction avec la complexité 20 n'est pas nécessairement plus propre qu'une fonction avec la complexité 30. Mais cela vaut la peine d'exécuter des mesures pour chercher de grandes différences.

une fois, j'ai passé en revue quelques douzaines de projets et l'un d'eux avait une valeur de complexité maximale d'environ 6 000, tandis que tous les autres avaient une valeur d'environ 100 ou moins. Ça m'a frappé à la tête comme une batte de baseball. Évidemment quelque chose inhabituel, et probablement du mal, qui se passait avec ce projet.

2

répondu John D. Cook 2008-11-22 15:22:13

nous sommes programmeurs. On aime les chiffres.

aussi, qu'allez-vous faire, ne pas décrire la taille de la base de code parce que "les lignes de métrique de code sont hors de propos"?

il y a certainement une différence entre un codebase de 150 lignes et un codebase de 150 millions, pour prendre un exemple stupide. Et il n'est pas difficile à obtenir.

1

répondu Thomas David Baker 2008-10-12 21:40:02

score 80 · Answer 1

les réponses dans ce fil sont un peu étranges comme ils parlent de:

"l'équipe", comme "le seul et unique bénéficiaire" de ces personnes ont dit métriques;
"la naissance", comme ils signifient rien en eux-mêmes.

1/ Indicateurs n'est pas pour un de la population, mais pour trois :

développeurs: ils sont concernés par instantané statique métriques de code concernant l'analyse statique du code (complexité cyclomatique, des commentaires de qualité, le nombre de lignes ...)
chefs de projet: ils sont concernés par daily 1519180920 "LIVE code metrics provenant de l'essai de l'Unité, de la couverture du code ,de l'essai d'intégration en continu
les entreprises commanditaires (ils sont toujours oubliés, mais ils sont la parties prenantes, celui qui paie pour le développement): ils sont concernés par hebdomadaire 1519180920 "Global Code metrics concernant la conception architecturale, la sécurité, les dépendances, ...

Toutes ces mesures peuvent être visionnées et analysées par les trois populations, bien sûr, mais chaque type est conçu pour être mieux utilisés par chaque groupe spécifique.

2/ Métriques, par eux-mêmes, représentent un snapshot du code, et cela signifie... rien!

c'est la combinaison de ces mesures, et les combinaisons de ces différents niveaux d'analyse qui peut indiquer un" bon "ou" mauvais "code, mais plus important encore, c'est la tendance de ces mesures qui est significative.

qui est la répétition de ces mesures ce qui donnera le réel valeur ajoutée, car ils aideront les chefs d'entreprise / chefs de projet / développeurs à prioriser parmi les différents correctifs de code possibles

en d'autres termes, votre question sur la "fascination des mesures" pourrait se référer à la différence entre:

"beau" code (mais qui est toujours dans l'œil de celui qui regarde-coder)
"bon" code (qui fonctionne, et peut prouver qu'il fonctionne)

ainsi, par exemple, une fonction avec une complexité cyclomatique de 9 pourrait être définie comme "belle", par opposition à une longue fonction alambiquée de complexité cyclomatique de 42.

mais, si:

cette dernière fonction a une constante complexité, combinée avec une couverture de code de 95%,
alors que le premier a une augmentation complexité, combiné avec une couverture de... 0%,

on pourrait argumenter:

le dernier représente un " bon " code (il fonctionne, il est stable, et si il faut changer, on peut vérifie s'il fonctionne encore après modifications),
le premier est un" mauvais " code (il encore besoin d'ajouter certains cas et conditions pour couvrir tout ce qu'il a à faire, et il n'est pas facile de faire quelques test de régression)

donc, pour résumer:

une seule métrique qui indique par elle-même toujours [...]

: pas beaucoup, sauf que le code peut être plus "beau", ce qui en soi ne signifie pas grand-chose...

est là un aperçu magique à tirer des mesures de code que j'ai négligé?

seule la combinaison 1519100920" et trend de metrics donne la vraie "vision magique" que vous recherchez.

score 21 · Answer 2

j'ai eu un projet que j'ai fait comme un travail d'une personne mesurée pour la complexité cyclomatique Il ya quelques mois. C'était ma première exposition à ce genre de mesures.

le premier rapport que j'ai reçu était choquant. Presque toutes mes fonctions ont échoué au test, même les (imho) très simples. J'ai contourné le problème de la complexité en déplaçant la sous-tâche logique dans les sous-programmes, même s'ils n'ont été appelés qu'une seule fois.

Pour l'autre moitié des routines ma fierté comme un programmeur a commencé et j'ai essayé de les réécrire d'une manière qu'ils font la même chose, juste plus simple et plus lisible. Cela a fonctionné et j'ai été en mesure d'obtenir le plus bas pour les clients yclomatic seuil de complexité.

finalement, j'ai presque toujours pu trouver une meilleure solution et un code beaucoup plus propre. La performance n'a pas souffert de cela (croyez - moi-je suis paranoïaque à ce sujet, et je vérifie le démontage de la sortie du compilateur assez souvent).

je pense que les mesures sont une bonne chose si vous les utilisez comme raison/motivation pour améliorer votre code. Il est important de savoir quand s'arrêter et de demander une subvention de violation métrique.

les mesures sont des guides et des aides, pas des fins en soi.

score 13 · Answer 3

la meilleure métrique que j'ai jamais utilisée est le score C. R. A. P. http://www.artima.com/weblogs/viewpost.jsp?thread=215899

essentiellement, c'est un algorithme qui compare la complexité cyclomatique pondérée avec la couverture de test automatique. L'algorithme ressemble à ceci: CRAP(m) = comp(m)^2 * (1 – cov(m)/100)^3 + comp(m) où comp(m) est la complexité cyclomatique de la méthode m, et cov (m) est la couverture du code d'essai fournie par les tests automatisés.

les auteurs de l'article ci-dessus mentionné (s'il vous plaît, allez le lire...ça vaut bien votre temps) suggérez un score maximum de 30 C. R. A. P. qui se décompose de la façon suivante:

Method’s Cyclomatic Complexity        % of coverage required to be
                                      below CRAPpy threshold
------------------------------        --------------------------------
0 – 5                                   0%
10                                     42%
15                                     57%
20                                     71%
25                                     80%
30                                    100%
31+                                   No amount of testing will keep methods
                                      this complex out of CRAP territory.

comme vous le voyez rapidement, le code d'écriture métrique récompense qui n'est pas complexe couplé avec une bonne couverture des tests (si vous écrivez des tests unitaires, et vous devriez l'être, et ne mesurez pas la couverture...Eh bien, vous apprécieriez probablement cracher dans le vent ainsi). ;- )

Pour la plupart de mes équipes de développement j'ai vraiment essayé d'obtenir la note C. R. A. P. en dessous de 8, mais s'ils avaient des raisons valables pour justifier la complexité supplémentaire qui était acceptable tant qu'ils ont couvert la complexité avec suffisamment de tests. (L'écriture de code complexe est toujours très difficile à tester...une sorte d'avantage caché de cette métrique).

la plupart des gens ont eu du mal au départ à écrire un code qui leur permettrait de passer le score C. R. A. P. Mais avec le temps, ils ont écrit un meilleur code, un code qui avait moins de problèmes, et le code était plus facile à déboguer. De toute métrique, c'est celui qui a le moins de préoccupations et le plus grand avantage.

score 9 · Answer 4

pour moi la métrique la plus importante qui identifie le mauvais code est la complexité cyclomatique. Presque toutes les méthodes dans mes projets sont en dessous de CC 10 et les bogues sont invariablement trouvés dans les méthodes héritées avec CC plus de 30. Haut CC indique habituellement:

code écrit en hâte (ie. il n'y avait pas de temps pour trouver une solution élégante et non pas parce que le problème nécessitait une solution complexe)
code non testé (personne n'écrit des tests pour de telles bêtes)
code qui a été corrigé et corrigé à de nombreuses reprises (c.-à-d. criblé avec les fi et les commentaires todo)
une cible de choix pour la refactorisation

score 8 · Answer 5

une bonne révision du code ne remplace pas un bon outil d'analyse statique, qui ne remplace évidemment pas une bonne série d'essais unitaires, maintenant les essais unitaires ne sont pas bons sans une série d'essais de réception......

les mesures de Code sont un autre outil à mettre dans votre boîte à outils, ils ne sont pas une solution en soi ils sont juste un outil à utiliser comme approprié (avec bien sûr tous les autres outils dans votre boîte!).

score 6 · Answer 6

mon opinion très subjective est que les mesures de code expriment la fascination institutionnelle irrésistible d'être en mesure de quantifier quelque chose d'intrinsèquement non quantifiable.

a un sens, d'une certaine manière, au moins psychologiquement - comment prendre des décisions sur quelque chose que vous ne pouvez pas évaluer ou comprendre? En fin de compte, bien sûr, vous ne pouvez pas évaluer la qualité à moins que vous êtes bien informé sur le sujet (et sont au moins aussi bons que ce que vous essayez d'évaluer) ou demandez à quelqu'un de bien informé, ce qui, bien sûr, remet le problème en question.

en ce sens, peut-être qu'une analogie raisonnable serait d'évaluer les étudiants par les résultats au SAT, c'est injuste et manque toutes sortes de subtilité, mais si vous avez besoin de quantifier, vous devez faire quelque chose.

ne pas dire que je pense que c'est une bonne mesure, seulement que je peux voir l'irrésistibilité constitutionnelle de lui. Et, comme vous l'avez souligné, il y a probablement quelques métrique (beaucoup de 500+ méthodes de ligne , haute complexité-probablement mauvais). Je n'ai jamais été à un endroit qui a acheté ça,cependant.

score 6 · Answer 7

il y a un code métrique en lequel je crois.

je travaille sur un gros système. Quand une seule nouvelle exigence m'est venue, je me suis mis à la coder. Quand j'ai fini et que j'ai réglé les bugs, je vérifie dans le système de contrôle de version. Ce système fait une différence, et compte tous les changements que j'ai faits.

plus ce nombre est petit, mieux c'est.

score 5 · Answer 8

les gens sont attirés à l'idée de moyens mécanistes pour comprendre et décrire le code. Si c'est vrai, pensez aux ramifications pour l'efficacité et la productivité!

je suis d'accord qu'une métrique pour" la bonté du code "est à peu près aussi sensible qu'une métrique pour" la bonne prose."Cependant, cela ne signifie pas que les mesures sont inutiles, peut-être simplement mal utilisées.

par exemple, valeurs extrêmes pour certaines mesures indiquer le chemin à problèmes possibles. Une méthode longue de 1000 lignes est probablement Impossible à maintenir. Code avec zéro unité code de test couverture probablement a plus de bogues que le code similaire avec beaucoup de tests. Un grand saut dans le code ajouté à un projet juste avant la publication qui n'est pas une bibliothèque de tiers est probablement cause pour l'attention supplémentaire.

je pense que si nous utilisons des mesures comme suggestion -- un drapeau rouge -- peut-être qu'elles peuvent être utiles. Le problème est que les gens commencent à mesurer la productivité en SLOC ou la qualité en pourcentage des lignes avec des tests.

score 5 · Answer 9

les mesures et les tests automatisés ne sont pas censés remplacer les examens complets du code.

ils ont juste accéléré les choses. Avec un vérificateur automatique, il est très facile de voir quelles conventions vous avez oublié de suivre, que vous utilisez les paquets et les méthodes désignés, etc. Vous pouvez voir ce que vous pouvez résoudre sans l'aide d'autres personnes.

les gestionnaires aiment aussi les mesures parce qu'ils ont l'impression d'obtenir un chiffre exact sur la productivité (bien que ce ne soit souvent pas le cas) et ils devraient être en mesure de mieux jongler avec les gens.

score 5 · Answer 10

les mesures ne sont utiles que si:

l'équipe les a développés
L'équipe a accepté
Ils sont utilisés pour identifier une zone spécifique

en général, toute métrique qui ne rentre pas dans cela souffrira de l'équipe qui l'optimise. Vous voulez mesurer des lignes de code? Regardez combien ils en écrivent! Vous voulez mesurer la couverture de code, par golly, Regardez-moi couvrez ce code!

je pense que les mesures peuvent être utiles pour identifier les tendances, et en fait, j'en ai vu quelques-unes utiles, comme tracer quand la construction casse, le code churn (nombre de lignes de code changeant tout au long du projet) et d'autres choses. Mais si l'équipe ne vient pas avec eux, ou s'ils ne sont pas d'accord ou ne les comprennent pas, vous êtes probablement dans un monde de souffrance.

score 4 · Answer 11

voici quelques mesures de complexité de stan4j(http://stan4j.com/).

Une éclipse structure de classe d'analyser l'outil.

j'aime cet outil et les paramètres. Je traite les mesures comme des statistiques, des indicateurs, des messages d'avertissement. Parfois, en raison de certaines méthodes ou certaines classes a vraiment de logique compliquée fait d'eux complexes, ce qui doit être fait est de garder un œil sur eux, examinez-les pour voir s'il est nécessaire de les remanier ou de les revoir. soigneusement, en raison de Normalement ils sont sujets à des erreurs. Aussi je l'utilise, d'analyser outil pour apprendre le code source, en raison de j'aime apprendre du complexe au simple.En fait il comprend quelques autres statistiques, telles que Robert C. Martin Métriques, Chidamber Et Kemerer Métriques,Comte de Métriques Mais je préfère celui-ci

Métriques De Complexité

Complexité Cyclomatique Mesures

Cyclomatic Complexité (CC) 151980920" La complexité cyclomatique d'une méthode est le nombre de points de décision dans le graphique de flux de contrôle de la méthode incrémenté d'un. Les points de décision se produisent aux énoncés if/for/while, aux clauses case/catch et aux éléments de code source similaires, où le flux de contrôle n'est pas seulement linéaire. Le nombre de points de décision (byte code) introduits par un seul énoncé (source code) peut varier, en fonction par exemple de la complexité des expressions booléennes. Plus la complexité cyclomatique la valeur d'une méthode est, le plus de cas d'essai sont nécessaires pour tester toutes les branches du graphique de flux de contrôle de la méthode.

Complexité Cyclomatique Moyenne Valeur moyenne de la métrique de complexité cyclomatique pour toutes les méthodes d'une application, d'une bibliothèque, d'un arbre de paquets ou d'un paquet.

Fat Mesures La Graisse métrique d'un objet est le nombre d'arêtes dans un graphe de dépendance de l'artefact. Le le type de graphe de dépendance dépend de la variante métrique et de l'artefact choisi:

matières grasses La métrique de Fat d'une application, d'une bibliothèque ou d'un arborescence de paquets est le nombre de bord de son graphique de dépendance sous-arbre. Ce graphique contient tous les enfants de l'artefact dans la hiérarchie de l'arborescence des paquets, y compris les paquets leaf. (Pour voir le graphique approprié dans la vue Composition, la bascule des paquets plats de L'Explorateur de Structure doit être désactivée. spectacle Bibliothèques bascule doit être activé si l'artefact choisi est une bibliothèque, sinon il doit être désactivé.)

la métrique de la graisse d'un paquet est le nombre de bords de son graphique de dépendance unitaire. Ce graphique contient toutes les classes de premier niveau du paquet.

la métrique de la matière grasse d'une classe est le dénombrement des arêtes du Graphe de ses membres. Ce graphique contient tous les champs, méthodes et classes de membres de la classe. (Ce graphique et la valeur de Fat ne sont disponibles que si le code l'analyse a été effectuée avec un membre du niveau de détail, et non avec la classe.)

la Graisse pour les Dépendances de la Bibliothèque (Fat - Bibliothèques) Le Fat pour la métrique des dépendances de bibliothèque d'une application est le nombre de bord de son graphe de dépendance de bibliothèque. Ce graphe contient toutes les bibliothèques de l'application. (Pour voir le graphe approprié dans la vue de Composition, la bascule des bibliothèques D'exposition de L'Explorateur de Structure doit être activée.)

matières grasses pour Dépendance À L'Égard Des Paquets Plats (Fat - Packages) Le Fat pour la métrique des dépendances de paquet plat d'une application est le nombre de bords de son graphique de dépendance de paquet plat. Ce graphique contient tous les paquets de la demande. (Pour voir le graphique approprié dans la vue Composition, la bascule des paquets plats de L'Explorateur de Structure doit être activée et la bascule des bibliothèques D'affichage doit être désactivée.)

le Fat pour les dépendances de paquet plat métrique d'une bibliothèque est le bord compter de son paquet plat graphe de dépendance. Ce graphique contient tous les paquets de la bibliothèque. (Pour voir le graphe approprié dans la vue Composition, les paquets plats de L'Explorateur de Structure et les toggles D'affichage des bibliothèques doivent être activés.)

Gras pour la Classe de Haut Niveau des Dépendances (Fat - Unités) Le Fat pour la métrique des dépendances de classe supérieure d'une application ou d'une bibliothèque est le nombre de bord de son graphique de dépendance d'unité. Ce graphique contient tout le haut les classes de niveau de l'application ou de la bibliothèque. (Pour des applications raisonnables, il est trop grand pour être visualisé et ne peut donc pas être affiché dans la vue de Composition. Les graphiques de dépendance d'unité ne peuvent être affichés que pour les paquets.)

score 2 · Answer 12

peut être utile pour déterminer l'amélioration ou la dégradation dans un projet, et peut certainement trouver le style et les violations de la convention, mais il n'y a pas de substitut pour faire des examens par les pairs code. Vous ne pouvez pas connaître la qualité de votre code sans eux.

Oh ... et cela suppose qu'au moins un des participants à votre révision du code a un indice.

score 2 · Answer 13

je suis d'accord avec vous que les mesures de code ne devraient pas remplacer une révision de code, mais je crois qu'elles devraient compléter les révisions de code. Je pense qu'il revient au vieux dicton: "on ne peut pas améliorer ce qu'on ne peut pas mesurer."Les mesures de Code peuvent fournir à l'équipe de développement des "odeurs de code" quantifiables ou des modèles qui peuvent nécessiter un examen plus approfondi. Les paramètres qui sont saisis dans la plupart des outils d'analyse statique sont généralement des paramètres qui ont été identifiés au cours de la recherche dans la courte histoire de notre domaine d'avoir une signification significative.

score 2 · Answer 14

les mesures ne remplacent pas la révision du code, mais elles sont beaucoup moins chères. Ils sont un indicateur plus que tout.

score 2 · Answer 15

une partie de la réponse est que certaines mesures de code peuvent vous donner un coup de couteau très rapide et initial à une réponse à la question: à quoi ressemble ce code?

même les 'lignes de code' peuvent vous donner une idée de la taille de la base de code que vous regardez.

comme mentionné dans une autre réponse, l'évolution des mesures vous donne le plus d'informations.

score 2 · Answer 16

les mesures d'elles-mêmes ne sont pas particulièrement intéressantes. C'est ce que l'on en fait qui compte.

par exemple, si vous mesuriez le nombre de commentaires par ligne de code, que considéreriez-vous comme une bonne valeur? Qui sait? Ou peut-être plus important encore, chacun a sa propre opinion.

maintenant si vous collectez assez d'informations pour pouvoir corréler le nombre de commentaires par ligne de code avec le temps nécessaire pour résoudre un bogue ou par rapport au nombre de bogues trouvés qui sont attribués au codage, alors vous pouvez commencer à trouver un nombre empiriquement utile.

il n'y a pas de différence entre l'utilisation de mesures dans un logiciel et l'utilisation de toute autre mesure de performance sur tout autre processus - d'abord vous mesurez, puis vous analysez, puis vous améliorez le processus. Si tu ne fais que mesurer, tu perds ton temps.

edit: En réponse à Steven A. Lowe commentaires - qui est absolument correct. Dans toute analyse de données, il faut veiller à distinguer entre une relation causale et une simple corrélation. Et le choix des paramètres sur la base de l'adéquation est important. Il est inutile d'essayer de mesurer la consommation de café et d'attribuer la qualité du code (même si je suis sûr que certains ont essayé ;-) )

mais avant que vous puissiez trouver la relation (causale ou non) vous devez avoir les données.

La sélection des données à collecter est basé sur ce processus vous souhaitez vérifier ou améliorer. Par exemple, si vous essayez d'analyser le succès de vos procédures de révision de code (en utilisant votre propre définition de "succès", que ce soit la réduction des bogues ou des bogues de codage, ou des délais d'exécution plus courts ou autre), alors vous sélectionnez des mesures qui mesurent le taux total de bogues et le taux de bogues dans le code révisé.

donc avant de collecter les données, vous devez savoir ce que vous voulez en faire. Si la métrique est le moyen, qu'est-ce que la fin?

score 2 · Answer 17

Je ne pense pas que de petits changements dans les paramètres soient significatifs: une fonction avec la complexité 20 n'est pas nécessairement plus propre qu'une fonction avec la complexité 30. Mais cela vaut la peine d'exécuter des mesures pour chercher de grandes différences.

une fois, j'ai passé en revue quelques douzaines de projets et l'un d'eux avait une valeur de complexité maximale d'environ 6 000, tandis que tous les autres avaient une valeur d'environ 100 ou moins. Ça m'a frappé à la tête comme une batte de baseball. Évidemment quelque chose inhabituel, et probablement du mal, qui se passait avec ce projet.

score 1 · Answer 18

nous sommes programmeurs. On aime les chiffres.

aussi, qu'allez-vous faire, ne pas décrire la taille de la base de code parce que "les lignes de métrique de code sont hors de propos"?

il y a certainement une différence entre un codebase de 150 lignes et un codebase de 150 millions, pour prendre un exemple stupide. Et il n'est pas difficile à obtenir.

Las etiquetas más populares

Quelle est la fascination avec les mesures de code? [fermé]

18 réponses