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

Question

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

Образец 1 ( Показатель МИ 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 ( Показатель МИ 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))), я не должен. Я бы, очевидно, просто играл с числами, и на самом деле это уже не читаемо и не обслуживаемо. Мне любопытно, что логика может быть в этом увеличении. Это явно не количество строк.

Answer 1

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

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

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

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

Answer 2

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

Answer 3

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

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

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

Answer 4

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