Code de Visual Studio métrique et l'indice de maintenabilité cas de commutation

Question

En tant que personne qui aime suivre les meilleures pratiques,

Si j'exécuter des métriques de code (clic droit sur le nom du projet dans l'explorateur de solution et sélectionnez "Calculer le code Metrics" - Visual Studio 2010):

    public static string GetFormFactor(int number)
    {
        string formFactor = string.Empty;
        switch (number)
        {
            case 1:
                formFactor = "Other";
                break;

            case 2:
                formFactor = "SIP";
                break;

            case 3:
                formFactor = "DIP";
                break;

            case 4:
                formFactor = "ZIP";
                break;

            case 5:
                formFactor = "SOJ";
                break;
        }

        return formFactor;
    }

Il me donne un indice de maintenabilité 61

(bien sûr cela est insignifiant si vous avez seulement cela, mais si vous utilisez un utilitaire comme la philosophie de la classe est de faire des trucs comme ça, votre classe utilitaire aura l'indice de maintenabilité bien pire ..)

Quelle est la solution pour cela?

Answer 1

Tout d'abord: 61 est considéré comme code maintenable. Pour l'indice de maintenabilité, 100 est très facile à maintenir le code, alors que 0 est difficile à maintenir.

• = 0-9 dur pour maintenir
• 10-19 = modérée à maintenir
• 20-100 = bon pour maintenir

L'indice maintenabilité est basé sur trois indicateurs de code: A savoir la Halstead Volumen, la complexité cyclomatique et de lignes de code et sur la base formules suivantes:

  

MAX (0, (171 à 5,2 * ln (Halstead   Volume) - 0,23 * (Cyclomatic   Complexité) - 16,2 * Dans (Lignes de   Code)) * 100/171)

En fait, dans votre exemple la cause de la faible valeur de l'indice de maintenabilité est la complexité cyclomatique. Cette mesure est calculée sur la base des différents chemins d'exécution du code. Malheureusement, la mesure ne correspond pas nécessairement avec « la lisibilité humaine » du code.

Exemples que votre résultat de code à très faibles valeurs d'index (rappelez-vous, des moyens inférieurs plus difficiles à maintenir), mais en fait, ils sont très faciles à lire. Cette situation est commune lors de l'utilisation complexité cyclomatique pour évaluer le code.

Imaginez le code qui a un commutateur bloc pour les jours (lundi-dimanche) plus un commutateur bloc pour les mois (Jan-Dc). Ce code sera très lisible et maintenable mais se traduira par une énorme complexité cyclomatique et donc dans un très faible indice de maintenabilité dans Visual Studio 2010.

Ceci est un fait bien connu de la métrique et doit être envisagée si le code est jugé sur la base des chiffres. Plutôt que de regarder le nombre absolu, les chiffres doivent être surveillés au fil du temps à comprendre comme un indicateur pour le changement du code. Par exemple. si l'indice de maintenabilité était toujours à 100 et tout à coup est descendu à 10 INSPECTER le changement qui a causé cela.

Answer 2

L'indice de maintenabilité pourrait être plus élevé en raison de l'absence de la méthode d'extension que vous choisissez pour votre solution.

La bonne solution (Mark Simpson a abordé ci-dessus) est celui qui peut être étendu à utiliser un nouveau facteur de forme sans le code en cours de reconstruction - déclarations commutateur / cas dans le code sont toujours un signe que la conception orientée objet a été oublié et devrait toujours être considérée comme une mauvaise odeur de code.

Personnellement, je mettre en œuvre ...

interface IFormFactor
{
    // some methods
}

class SipFormFactor : IFormFactor...

class DipFormFactor : IFormFactor...

Etc.

... et ont les méthodes de l'interface fournir la fonctionnalité souhaitée -. Vous pouvez penser [je suppose] comme étant similaire à motif GoF Commande

De cette façon, vos méthodes de niveau supérieur peuvent être juste ...

MyMethod(IFormFactor factor)
{
    // some logic...

    factor.DoSomething();

    // some more logic...
}

... et vous pouvez venir à une date ultérieure et d'introduire un nouveau facteur de forme sans avoir à changer ce code comme vous le feriez avec la clause de commutateur codé en dur. Vous trouverez également cette approche facilement se prête également à TDD (vous devriez finir avec cela si vous faites TDD correctement) car il est facile pour se moquant.

Answer 3

Je sais que cette réponse est très en retard, mais je me suis intéressé que personne ne PUT la solution dictionnaire. J'ai trouvé que face à d'énormes déclarations de commutation qui sont données axées sur ce genre, il est souvent plus lisible pour réduire le commutateur cas dans un dictionnaire.

public static readonly IDictionary<int, string> Factors = new Dictionary<int, string> {
   { 1, "Other" },
   { 2, "SIP" },
   { 3, "DIP" },
   { 4, "ZIP" },
   { 5, "SOJ" }
};

public static string GetFormFactor2(int number)
{
   string formFactor = string.Empty;
   if (Factors.ContainsKey(number)) formFactor = Factors[number];
   return formFactor;
}

Cela vous donne un indice de maintenabilité 74 - légèrement inférieur à la solution de tableau en raison de la classe de couplage à un dictionnaire, mais je pense qu'il est plus général parce que cela fonctionne pour un certain nombre de types que vous auriez normalement allumer. Comme la très bien solution de tableau, il adapte et supprime beaucoup de code répétitif.

D'une manière générale, en utilisant une approche axée sur les données peut aider votre code pour être plus clair, car il sépare les éléments importants (dans ce cas, une condition et un résultat) de la croute (dans ce cas, l'interrupteur cas) .

Answer 4

Deux choses viennent à l'esprit:

Utilisez un ENUM de se marier la description et la valeur

public enum FormFactor
{
    Other = 1,
    SIP = 2,
    etc.
}

Utiliser une classe ou struct pour représenter chaque facteur de forme

public class FormFactor 
{
    public int Index { get; private set; }
    public string Description { get; private set; }

    public FormFactor(int index, string description)
    {
        // do validation and assign properties
    }
}

Answer 5

Je le ferais de cette façon et oublier l'indice de maintenabilité:

public static string GetFormFactor(int number)
{
    switch (number)
    {
        case 1: return "Other";
        case 2: return "SIP";
        case 3: return "DIP";
        case 4: return "ZIP";
        case 5: return "SOJ";
    }

    return number.ToString();
}

à mon humble avis facile à lire et facile à changer.

Answer 6

Je ne sais pas combien il est important, mais ce qui suit obtient un 76:

private static string[] _formFactors = new[] { null, "Other","SIP","DIP", "ZIP", "SOJ"};
public static string GetFormFactor2(int number)
{
    if (number < 1 || number > _formFactors.Length)
    {
        throw new ArgumentOutOfRangeException("number");
    }

    return _formFactors[number];
}

Answer 7

Il est clair que pour moi le Enum méthode est la plus maintenable car il ne comporte pas de chaînes codées en dur donc pas faute de frappe problème et la compilation vérification de la syntaxe. Seules les restrictions sont les règles de nommage.