En tant que personne qui aime suivre les meilleures pratiques,
Si je jette des métriques de code (clic droit sur le nom du projet dans l'explorateur de solution et sélectionnez "Calculer les métriques de code" - Visual Studio 2010) sur: < pré> xxx
Cela me donne un indice de main-d'œuvre de (bien sûr, cela est insignifiant si vous n'avez que cela, mais si vous utilisez un utilitaire Comme la classe Whos Philosophy fait des choses comme ça, votre classe de services publics aura l'indice de maintenabilité beaucoup plus pire ..) Quelle est la solution pour cela?
7 Réponses :
Deux choses de printemps à l'esprit:
Utilisez une énumération pour épouser la description et la valeur
Hmm, je suis avec quelqu'un difficile de comprendre votre situation. Pouvez-vous s'il vous plaît être un peu plus précis? Un exemple plus détaillé? Salutations
Je ne sais pas combien cela compte, 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];
}
Oui, c'est une solution, mais pas très élégant: P Je pensais à une manière structurée de le faire. Des idées?
Je le ferais de cette façon et oubliez l'index de la 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();
}
C'est comme ça que j'ai fait .. mais je veux vraiment savoir s'il y a une autre solution
Je trouve les méthodes de tableau et d'énumération mentionnées ci-dessous moins lisibles et moins à maintenir.
Tout d'abord: 61 est considéré comme un code maintenu. Pour l'indice de maintenabilité, 100 est très facile à maintenir le code, tandis que 0 est difficile à maintenir.
L'indice de maintenabilité est basé sur trois métriques de code: à savoir le volumen halstead, la complexité cyclomatique et les lignes de code et basé sur le Formule suivante :
max (0, (171 - 5.2 * ln (Halstead Volume) - 0,23 * (cyclomatique Complexité) - 16,2 * ln (lignes de Code)) * 100/171)
En fait, dans votre exemple, la cause première de la valeur basse de l'indice de maintenabilité est la complexité cyclomatique. Cette métrique est calculée sur la base des différents chemins d'exécution du code. Malheureusement, la métrique ne s'aligne pas nécessairement avec la "lisibilité humaine" du code.
Exemples Comme votre code aboutit à des valeurs d'index très faibles (rappelez-vous, plus fort signifie maintenir) mais en fait, ils sont très faciles à lire. Ceci est courant lors de l'utilisation de la complexité cyclomatique pour évaluer le code.
Imagine code comportant un bloc de commutation pendant des jours (Sun-Sun) plus un bloc de commutation pendant des mois (janvier-déc). Ce code sera très lisible et maintenu, mais entraînera une énorme complexité cyclomatique et donc dans un indice de maintenabilité très faible dans Visual Studio 2010.
Ceci est un fait bien connu sur la métrique et doit être considéré 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 pour comprendre en tant qu'indicateur pour le changement du code. Par exemple. Si l'indice de maintenabilité était toujours à 100 et est tombé soudainement jusqu'à 10, vous devez inspecter le changement qui a provoqué cela.
Remarque: L'index est basé sur la moyenne HV, CC et CC, et LOC. Pour une analyse ultérieure de l'indice de maintenabilité, les coefficients, les seuils et son histoire, voir mon blog post " pense à deux fois avant d'utiliser l'indice de maintenabilité ."
Clairement pour moi, la méthode Enum est la plus maintenue car elle n'implique pas de chaînes codées dures, pas de problème de typo et de la vérification de la syntaxe de compilation. Seules les restrictions sont des règles de dénomination.
L'indice de maintenabilité pourrait être plus élevé en raison du manque d'extensibilité dans la méthode que vous choisissez pour votre solution.
La solution correcte (Mark Simpson touchée ci-dessus) est celle qui peut être étendue à une nouvelle forme Facteur sans le code en cours de reconstruction - Les déclarations de commutation / cas dans le code sont toujours un signe que OO Design a été oublié et doit toujours être considérée comme une mauvaise odeur de code. p>
personnellement, je voudrais mettre en œuvre ...
MyMethod(IFormFactor factor)
{
// some logic...
factor.DoSomething();
// some more logic...
}
Je sais que cette réponse est très tard, mais j'étais intéressé à ce que personne ne propose la solution de dictionnaire encore. J'ai constaté que lors de la gestion des énormes déclarations de commutation qui sont orientées sur les données comme ceci, il est souvent plus lisible pour réduire l'échangeur de dictionnaire 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;
}