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

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);   
}

我理解指标在更广泛的背景和理解之外是没有意义的，程序员应该行使自由裁量权。 虽然我可以通过return Convert.ToBase64String(sha1.ComputeHash(Encoding.Unicode.GetBytes(plainText)))将分数提高到76，但我不应该。 我显然只是在玩数字，而且在那一点上它并不是真正的可读性或可维护性。 我很好奇这个案例增加背后的逻辑是什么。 这显然不是行数。

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

Answer 4

我自己，我宁愿看看return Convert.ToBase64String(sha1.ComputeHash(Encoding.Unicode.GetBytes(plainText))) ; 这是应该而不是不应该 。 这种形式的优点是简洁地表达了实际的数据流; 如果你添加了一堆临时变量和赋值，我现在必须读取变量名称并匹配它们的出现次数以查看实际发生的情况。