为什么这个可维护性指数会增加？

Question

如果有人能够根据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))),但我不应该.我显然只是在玩数字,而且在那一点上它并不是真正的可读性或可维护性.我很好奇这个案例增加背后的逻辑是什么.这显然不是行数.

Answer 1

让你的变量全部放在顶部,这样你就知道函数中的内容更"可维护",至少是那些决定代码指标规则的人所想的.

这是否真的如此？完全取决于处理代码的团队.看起来你已经通过问题的基调知道了这一点,但几乎所有的代码指标都带有一丝盐,它们是人们认为最好的东西,对于微软以外的团队来说可能不是真的...做什么是最好的对于你的团队,而不是某些计算器告诉你的.

我不会做出对您和您的团队的编码性能有害的更改(除非是实际性能或改进的错误处理等),您认为这些更改对于在度量标准板上获得几点不太可读.

所有这一切,如果它给你一个非常低的可维护性,可能有一些值得关注或分解成较小的块,因为非常低的分数可能不是那么可接受,几乎任何团队.

Answer 2

这是一个老问题,但我只是想我补充一点,MI部分基于Halstead音量,这是基于'运算符'和'操作数'的计数.如果按类型声明变量是"运算符",则这意味着样本2具有较少的运算符,从而更改分数.一般而言,因为MI是一种统计测量,所以在处理小样本时(例如一个简短的方法),它的用处有限.

Answer 3

由于变量声明与使用它们的位置之间的距离增加.

规则是尽可能地减少变量跨度,跨度是变量声明与使用位置之间的距离.随着距离的增加,引入后来代码的风险会增加,影响变量而程序员不会在代码中进一步意识到影响.

这是一本好书的链接,涵盖了这个以及许多其他有关代码质量的主题. http://www.amazon.com/Code-Complete-Practical-Handbook-Construction/dp/0735619670/ref=dp_ob_title_bk