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 volume，它基于'运营商'和'操作数'的计数。如果按类型声明变量是“运算符”，则这意味着样本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)));这是应该而不是不应该。这种形式的优点是简洁地表达了实际的数据流;如果你添加了一堆临时变量和赋值，我现在必须读取变量名称并匹配它们的出现次数以查看实际发生的情况。

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

4 个答案: