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

Я был бы благодарен, если кто-то мог бы объяснить мне различие между следующими двумя частями кода с точки зрения Метрических правил Кода Visual Studio. Почему Пригодность для обслуживания Индексирует увеличение немного, если я не инкапсулирую все в 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))), Я не был должен. Я ясно просто играл бы с числами, и это не действительно больше читаемо или удобно в сопровождении в той точке. Мне любопытно, хотя относительно того, чем логика могла бы быть позади увеличения в этом случае. Это - очевидно, не количество строки.

15
задан Timothy 14 July 2015 в 19:20
поделиться

3 ответа

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

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

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

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

16
ответ дан 1 December 2019 в 02:01
поделиться

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

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

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

7
ответ дан 1 December 2019 в 02:01
поделиться

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

0
ответ дан 1 December 2019 в 02:01
поделиться
Другие вопросы по тегам:

Похожие вопросы: