Почему этот индекс работоспособности увеличивается?

Я был бы признателен, если бы кто-нибудь мог объяснить мне разницу между следующими двумя частями кода с точки зрения правил Visual Studio Code Metrics. Почему индекс работоспособности немного увеличивается, если я не инкапсулирую все в using ( )?

Пример 1 (оценка MI 71)

public static String Sha1(String plainText)
{
    using (SHA1Managed sha1 = new SHA1Managed())
    {
        Byte[] text = Encoding.Unicode.GetBytes(plainText);
        Byte[] hashBytes = sha1.ComputeHash(text);
        return Convert.ToBase64String(hashBytes);    
    }
}

Пример 2 (оценка MI 73)

public static String Sha1(String plainText)
{
    Byte[] text, hashBytes;
    using (SHA1Managed sha1 = new SHA1Managed())
    {
        text = Encoding.Unicode.GetBytes(plainText);
        hashBytes = sha1.ComputeHash(text);
    }
    return Convert.ToBase64String(hashBytes);   
}

Я понимаю, что показатели не имеют смысла за пределами более широкого контекста и понимания, а программисты должны проявлять осмотрительность. Хотя я мог бы увеличить счет до 76 с помощью return Convert.ToBase64String(sha1.ComputeHash(Encoding.Unicode.GetBytes(plainText))), я не должен. Я бы явно просто играл с цифрами, и на данный момент он не является более читабельным или поддерживаемым. Мне любопытно, но как же логика может быть за этим увеличением. Это явно не количество строк.

Ответ 1

Имея ваши переменные, все выложенные наверху, чтобы вы знали, что в функции более "поддерживаемо", по крайней мере, то, что думает тот, кто решает правила для метрик кода.

Действительно ли это верно? Полностью зависит от команды, работающей над кодом. Кажется, вы уже знаете это по тону вопроса, но принимаете почти все кодовые метрики с кусочком соли, это то, что кто-то считает лучшим, что может быть неверно для команд за пределами microsoft... делать то, что лучше всего для вашей команды, а не то, что говорит вам какой-то калькулятор.

Я бы не вносил изменений, которые пагубно сказываются на производительности вашей команды и вашей команды (если только это не для реальной производительности или улучшения обработки ошибок и т.д.), которые, по вашему мнению, менее читабельны для получения нескольких точек на панели показателей.

Все сказанное, если оно дает вам очень низкую ремонтопригодность, возможно, стоит что-то взглянуть на мелкие куски или сломаться на них, так как очень низкий балл, вероятно, не так приемлем, почти для любой команды.

Ответ 2

Это старый вопрос, но я просто подумал, что добавлю, что MI частично основан на том Halstead, который основан на количество "операторов" и "операндов". Если объявление переменной по типу является "оператором", это будет означать, что в примере 2 меньше операторов, что приводит к изменению оценки. В общем, поскольку MI является статистическим измерением, он имеет ограниченную полезность при работе с малыми размерами выборки (например, одним коротким методом).

Ответ 3

Из-за увеличенного расстояния между объявлением переменных и их использованием.

Правило состоит в том, чтобы максимально уменьшить диапазон переменных, span - это расстояние между объявлением переменной и тем, где оно используется. По мере увеличения этого расстояния, риск увеличивается, а затем вводится код, влияющий на переменную, без того, чтобы программист понимал, что воздействие ниже в коде.

Вот ссылка на хорошую книгу, которая охватывает эту и многие другие темы по качеству кода. http://www.amazon.com/Code-Complete-Practical-Handbook-Construction/dp/0735619670/ref=dp_ob_title_bk

Ответ 4

Я, скорее, посмотрю return Convert.ToBase64String(sha1.ComputeHash(Encoding.Unicode.GetBytes(plainText))); это скорее должно, а не должно. Преимущество этой формы заключается в том, чтобы кратко выразить фактический поток данных; если вы добавляете кучу временных переменных и назначений, теперь мне нужно прочитать имена переменных и сопоставить их случаи, чтобы увидеть, что на самом деле происходит.