Quelle (s) métrique (s) du code vous convainquez que le code fourni est & # 8220; merdique & # 8221 ;? [fermé]

Question

Lignes de code par fichier, méthodes par classe, complexité cyclomatique, etc. Les développeurs résistent et contournent la plupart d'entre eux! Il y a un bon article de Joel (il n'est pas temps de le trouver maintenant). ).

Quelle (s) mesure (s) de code que vous recommandez d'utiliser pour identifier automatiquement le "code de merde"?

Qu'est-ce qui peut convaincre le plus (vous ne pouvez pas nous convaincre tous de faire une métrique de merde!: O)) des développeurs que ce code est un "crap"?.

Seules les mesures pouvant être automatiquement mesurées comptent!

Answer 1

Aucune métrique concernant le style de codage ne fait partie d'un tel avertissement.

Pour moi, il s'agit de l ' analyse statique du code , qui peut vraiment être activée tout le temps:

• complexité cyclomatique (détecté par le style de contrôle)
• détection du cycle de dépendance (via findbugs, par exemple)
• erreurs critiques détectées par, par exemple, findbugs.

Je mettrais le test de couverture dans une seconde étape, car de tels tests peuvent prendre du temps.

N'oubliez pas que " merdique " les codes ne sont pas détectés par les métriques, mais par la combinaison et évolution (comme dans " tendance ) des métriques: voir la Quelle est la fascination des métriques de code? question.

Cela signifie que vous ne devez pas simplement recommander des métriques de code pour "identifier automatiquement le" code pourri ", mais vous devez également recommander la bonne combinaison et l'analyse de tendance pour aller avec ces métriques.

Dans une petite annonce, je partage votre ;), et je ne partage pas le point de vue de tloach (dans les commentaires d’une autre réponse) "Posez une question vague, obtenez une réponse vague" il dit ... votre question mérite une réponse spécifique.

Answer 2

Ce n'est pas une solution automatisée, mais je trouve les WTF par minute utiles.

_{(source: osnews.com )}

Answer 3

Nombre d'avertissements générés par le compilateur lors de la construction.

Answer 4

Nombre de lignes commentées par ligne de code de production. Généralement, cela indique un programmeur négligent qui ne comprend pas le contrôle de version.

Answer 5

Les développeurs se préoccupent toujours des métriques utilisées contre eux et de l'appel "Crappy". le code n'est pas un bon début. Ceci est important car si vous craignez que vos développeurs jouent autour d'eux, n'utilisez pas les mesures pour tout ce qui est à leur avantage / leur inconvénient.

Pour que cela fonctionne le mieux, ne laissez pas la métrique vous dire où le code est pourri, mais utilisez la métrique pour déterminer où vous devez regarder. Vous regardez en examinant le code et la décision de résoudre le problème appartient au développeur et au relecteur. Je voudrais également erreur du côté du développeur contre la métrique. Si le code continue de faire son apparition sur la métrique mais que les critiques le jugent bon, laissez-le tranquille.

Mais il est important de garder à l’esprit cet effet de jeu lorsque vos statistiques commencent à s’améliorer. Super, j'ai maintenant une couverture de 100%, mais les tests unitaires sont-ils bons? La métrique me dit que je vais bien, mais je dois quand même y jeter un coup d'œil et voir ce qui nous a amenés là-bas.

En bout de ligne, l'humain l'emporte sur la machine.

Answer 6

nombre de variables globales.

Answer 7

• Tests inexistants (révélés par la couverture de code). Ce n'est pas nécessairement un indicateur que le code est mauvais, mais c'est un gros signe d'avertissement.

• blasphème dans les commentaires.

Answer 8

Les métriques seules n'identifient pas le code de merde. Cependant, ils peuvent identifier un code suspect.

Il existe de nombreuses mesures pour le logiciel OO. Certains d'entre eux peuvent être très utiles:

• Taille moyenne de la méthode (en LOC / Instructions ou en complexité). Les grandes méthodes peuvent être un signe de mauvaise conception.
• Nombre de méthodes remplacées par une sous-classe. Un grand nombre indique une mauvaise conception de classe.
• Index de spécialisation (nombre de méthodes substituées * niveau d'imbrication / nombre total de méthodes). Les nombres élevés indiquent des problèmes possibles dans le diagramme de classes.

Il existe beaucoup plus de statistiques viables, et elles peuvent être calculées à l'aide d'outils. Cela peut être une aide précieuse pour identifier un code de merde.

Answer 9

• variables globales
• nombres magiques
• rapport code / commentaire
• couplage fort (par exemple, en C ++, vous pouvez le mesurer en regardant les relations de classe ou le nombre de fichiers cpp / header qui se croisent mutuellement
• const_cast ou d'autres types de transtypage dans la même base de code (pas avec les bibliothèques externes)
• de grandes portions de code commentées et laissées là

Answer 10

Mon drapeau d'avertissement préféré: le commentaire libre. Cela signifie généralement que le codeur n’a pas cessé d’y réfléchir; plus cela rend automatiquement difficile à comprendre, donc le ratio de merde est élevé.

Answer 11

À première vue: application culte du fret par des idiomes de code.

Dès que je regarde de plus près: bugs évidents et idées fausses du programmeur.

Answer 12

Mon pari: combinaison de la complexité cyclomatique (CC) et de la couverture de code provenant de tests automatisés (TC).

CC | TC

 2 | 0%  - good anyway, cyclomatic complexity too small

10 | 70% - good

10 | 50% - could be better

10 | 20% - bad

20 | 85% - good

20 | 70% - could be better

20 | 50% - bad

...

crap4j - outil possible (pour Java) et explication de concept ... à la recherche d'un outil convivial pour C # : (

Answer 13

Nombre de commentaires sans valeur en commentaires significatifs:

'Set i to 1'
Dim i as Integer = 1

Answer 14

Je ne crois pas qu'il existe une telle métrique. À l'exception du code qui ne fait pas ce qu'il est censé faire (ce qui est un niveau de foutaise supplémentaire), le code "merdique" signifie un code difficile à maintenir. Cela signifie généralement que le responsable de la maintenance a du mal à comprendre, ce qui est toujours dans une certaine mesure une chose subjective, tout comme une mauvaise écriture. Bien sûr, il y a des cas où tout le monde convient que l'écriture (ou le code) est de mauvaise qualité, mais il est très difficile d'écrire une métrique à ce sujet.

De plus, tout est relatif. Le code effectuant une fonction très complexe, avec une mémoire minimale, optimisé pour chaque dernier cycle de vitesse, semblera très mauvais comparé à une fonction simple sans aucune restriction. Mais ce n’est pas nul - c’est juste ce qu’il faut faire.

Answer 15

Malheureusement, il n’ya pas de métrique à ma connaissance. Quelque chose à garder à l'esprit est que, peu importe ce que vous choisissez, les programmeurs vont jouer avec le système pour que leur code paraisse bien. J'ai vu cela partout avec n'importe quel type de " automatique " la métrique est mise en place.

Answer 16

Un grand nombre de conversions vers et depuis des chaînes. Généralement, c'est un signe que le développeur ne comprend pas bien ce qui se passe et qu'il essaye simplement des choses au hasard jusqu'à ce que quelque chose fonctionne. Par exemple, j'ai souvent vu du code comme celui-ci:

   object num = GetABoxedInt();
//   long myLong = (long) num;   // throws exception
   long myLong = Int64.Parse(num.ToString());

quand ils voulaient vraiment:

   long myLong = (long)(int)num;

Answer 17

Je suis surpris que personne n'ait mentionné crap4j .

Answer 18

• Faites attention au rapport entre les classes de modèle et les classes standard. Un ratio élevé indiquerait une cas de patternite
• Recherche des nombres magiques non définis comme constantes
• Utilisez un utilitaire de correspondance de modèle pour détecter le code potentiellement dupliqué

Answer 19

Parfois, vous le savez juste quand vous le voyez. Par exemple, ce matin, j’ai vu:

void mdLicense::SetWindows(bool Option) {
  _windows = (Option ? true: false);
}

Je devais juste me demander: "Pourquoi quelqu'un ferait-il cela?".

Answer 20

La couverture de code a une certaine valeur, mais sinon, je me fie davantage au profilage de code pour dire si le code est de mauvaise qualité.

Answer 21

Proportion de commentaires qui incluent le blasphème par rapport aux commentaires qui n'en contiennent pas.

Plus élevé = meilleur code.

Answer 22

Lignes de commentaires / Lignes de code

valeur > 1 - > mauvais (trop de commentaires)

valeur < 0,1 - > mauvais (pas assez de commentaires)

Ajustez les valeurs numériques en fonction de votre propre expérience; -)

Answer 23

Je privilégie une approche à plusieurs niveaux, le premier étant une lisibilité raisonnable, compensée uniquement par la complexité du problème à résoudre. S'il ne réussit pas le test de lisibilité, je considère généralement que le code est moins que bon.

Answer 24

TODO: est commenté dans le code de production. Indique simplement que le développeur n'exécute pas ses tâches jusqu'à la fin.

Answer 25

Méthodes avec 30 arguments. Sur un service web. C'est tout.

Answer 26

Eh bien, vous pouvez utiliser différentes manières pour indiquer si un code est un bon code. En voici quelques-unes:

1. Cohesiveness: Eh bien, le bloc de code, qu'il s'agisse d'une classe ou d'une méthode, s'il sert plusieurs fonctionnalités, alors le code peut avoir une plus faible cohésion. Le code dont la cohésion est inférieure peut être qualifié de faible capacité de réutilisation. Ceci peut encore être qualifié de code à maintenabilité inférieure.

   1. Complexité du code: on peut utiliser la complexité cyclomatique de McCabe (nombre de points de décision) pour déterminer la complexité du code. La complexité du code étant élevée, elle peut être utilisée pour représenter du code moins convivial (difficile à lire et à comprendre).

   2. Documentation: un code contenant trop de document peut également être attribué à une qualité logicielle médiocre du point de vue de la convivialité du code.

Consultez la page suivante pour en savoir plus sur la liste de contrôle pour la révision du code. / p>

Answer 27

Ce billet de blog hilarant sur La métrique Code CRAP pourrait être utile.