Метрики Кода Visual Studio и индекс Пригодности для обслуживания случая переключателя
Как человек, который любит применять лучшие методы,
Если я выполняю метрики кода (щелчок правой кнопкой по названию проекта в проводнике решения, и выбор "Вычисляют Метрики Кода" - 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;
}
Это Дает мне индекс Пригодности для обслуживания 61
(конечно, это незначительно, если у Вас есть только это, но если Вы используете утилиту как класс, кто философия, делает материал как этот, Ваш служебный класс будет иметь пригодность для обслуживания, индексируют много худшее..)
Каково решение для этого?
4 ответа
Прежде всего: 61 считается обслуживаемым кодом. Для индекса ремонтопригодности 100 очень легко поддерживать код, а 0 трудно поддерживать.
- 0-9 = сложно поддерживать
- 10-19 = умеренно поддерживать
- 20-100 = хорошо поддерживать
Индекс ремонтопригодности основан на трех метриках кода: а именно Halstead Volumen, Cyclomatic Сложность и строки кода и основан на следующей формуле :
MAX (0, (171 - 5.2 * ln (Halstead Объем) - 0,23 * (Цикломатический Сложность) - 16,2 * пер (Линии Код)) * 100/171)
Фактически, в вашем примере основной причиной низкого значения индекса ремонтопригодности является цикломатическая сложность. Этот показатель рассчитывается на основе различных путей выполнения в коде. К сожалению, этот показатель не обязательно соответствует «удобочитаемости» кода.
Примеры в вашем коде приводят к очень низким значениям индекса (помните, что чем ниже, тем сложнее поддерживать), но на самом деле их очень легко читать. Это обычное явление при использовании Cyclomatic Complexity для оценки кода.
Представьте себе код, в котором есть блок переключения для дней (пн-вс) плюс блок переключения для месяцев (январь-декабрь). Этот код будет очень удобочитаемым и обслуживаемым, но приведет к огромной цикломатической сложности и, следовательно, к очень низкому индексу ремонтопригодности в Visual Studio 2010.
Это хорошо известный факт о метрике, и его следует учитывать, если код будет оцениваться на основе на рисунках. Вместо того, чтобы смотреть на абсолютное число, цифры следует отслеживать с течением времени, чтобы понимать их как индикатор изменения кода. Например. если индекс ремонтопригодности всегда был на уровне 100 и внезапно упал до 10, вы должны проверить изменение, вызвавшее это.
На ум приходят две вещи:
Используйте перечисление, чтобы объединить описание и значение
public enum FormFactor
{
Other = 1,
SIP = 2,
etc.
}
Используйте класс или структуру для представления каждого форм-фактора
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
}
}
Я бы сделайте это так и забудьте про индекс ремонтопригодности:
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();
}
ИМХО легко читать и легко менять.
Я не знаю, насколько это важно, но следующее получает 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];
}