为什么可维护性指数会增加？
如果有人可以根据 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);
}
我知道指标在外部毫无意义更广泛的背景和理解，程序员应该谨慎行事。虽然我可以通过 return Convert.ToBase64String(sha1.ComputeHash(Encoding.Unicode.GetBytes(plainText))) 将分数提高到 76，但我不应该这么做。显然，我只是在玩数字，而此时它实际上不再具有可读性或可维护性。我很好奇这种情况下增加背后的逻辑可能是什么。显然不是行数。
I would be appreciative if someone could explain to me the difference between the following two pieces of code in terms of Visual Studio's Code Metrics rules. Why does the Maintainability Index increase slightly if I don't encapsulate everything within using ( )?
Sample 1 (MI score of 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);
}
}
Sample 2 (MI score of 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);
}
I understand metrics are meaningless outside of a broader context and understanding, and programmers should exercise discretion. While I could boost the score up to 76 with return Convert.ToBase64String(sha1.ComputeHash(Encoding.Unicode.GetBytes(plainText))), I shouldn't. I would clearly be just playing with numbers and it isn't truly any more readable or maintainable at that point. I am curious though as to what the logic might be behind the increase in this case. It's obviously not line-count.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
将变量全部放在顶部，这样您就知道函数中的内容更“可维护”，至少决定代码指标规则的人是这么认为的。
这到底是不是真的呢？完全取决于编写代码的团队。看起来您已经通过问题的语气知道了这一点，但是对几乎所有代码指标都持保留态度，它们是某人认为最好的，对于外部团队来说可能并非如此微软...做对您的团队最有利的事情，而不是某些计算器告诉您的事情。
我不会做出对您和您的团队的编码性能有害的更改（除非是为了实际性能或改进的错误处理等），您认为这些更改对于在指标板上获得一些分数来说可读性较差。
话虽这么说，如果它给你一个非常低的可维护性，那么可能有一些东西值得一看或分解成更小的块，因为对于几乎所有的东西来说，非常低的分数可能不太可接受。团队。
Having your variables all laid out at the top so you know what's in the function is more "maintainable", at least that's what whoever decides the rules for the code metrics thinks.
Whether that's actually true? Totally depends on the team working on the code. It seems you already know this by the tone of the question, but take almost all code metrics with a grain of salt, they're what someone thinks is best, that may not be true for teams outside of microsoft...do what's best for your team, not what some calculator tells you.
I wouldn't make changes that are detrimental to your and your team's coding performance (unless it's for actual performance or improved error handling, etc) that you think are less readable for getting a few points on the metrics board.
All that being said, if it gives you a very low maintainability, there probably is something worth looking at or breaking down into smaller chunks, as a very low score is probably not so acceptable, for pretty much any team.
这是一个老问题，但我只是想补充一点，MI 部分基于 Halstead 体积，它基于“运算符”和“操作数”的计数。如果按类型声明变量是“运算符”，则这意味着示例 2 的运算符较少，从而改变分数。一般来说，由于 MI 是一种统计测量，因此在处理小样本量（如单个短方法）时，它的用处有限。
This is an old question, but I just thought I'd add that the MI is partially based on Halstead volume, which is based on a count of 'operators' and 'operands'. If declaration of a variable by type is an 'operator', this would mean that Sample 2 has fewer operators, thus changing the score. In general, because the MI is a statistical measurement, it is of limited usefulness when dealing with small sample sizes (like a single short method.)
因为变量的声明和使用它们的地方之间的距离增加了。
规则是尽可能减少变量跨度，跨度是变量的声明和使用位置之间的距离。随着这个距离的增加，随后引入影响变量的代码而程序员没有意识到代码中进一步的影响的风险就会增加。
这是一本好书的链接，该书涵盖了这个问题以及许多其他有关代码质量的主题。
http://www.amazon.com/Code-Complete-Practical-Handbook-Construction/dp /0735619670/ref=dp_ob_title_bk
Because of the increased distance between the declaration of your variables and where they are used.
The rule is to reduce the variable span as much as possible, the span is the distance between the declaration of the variable and where it is used. As this distance increases, the risk increases that later code is introduced that affects the variable without the programmer realising the impact further down in the code.
Here is a link to a good book that covers this and many other topics on code quality.
http://www.amazon.com/Code-Complete-Practical-Handbook-Construction/dp/0735619670/ref=dp_ob_title_bk
我自己，我宁愿看到
return Convert.ToBase64String(sha1.ComputeHash(Encoding.Unicode.GetBytes(plainText)));这是应该而不是不应该。这种形式的优点是能够简洁地表达实际的数据流；如果您添加一堆临时变量和赋值，我现在必须读取变量名称并匹配它们的出现次数以查看实际发生的情况。Myself, I'd rather see
return Convert.ToBase64String(sha1.ComputeHash(Encoding.Unicode.GetBytes(plainText))); it's a should rather than a shouldn't. This form has the advantage of concisely expressing the actual data-flow; if you add a bunch of temporary variables and assignments, I now have to read the variable names and match up their occurrences to see what's actually happening.