标准.NET项目的可维护性指数的价值应该是多少？

Question

我正在使用多个企业级.NET项目。作为代码审查任务的一部分，我们使用Visual Studio工具为这些项目计算代码度量（可维护性指数和循环复杂性）。

现在，对于可维护性指数，MSDN博客（即绿区！）建议的可接受范围是20-100。但就指标而言，这是一个非常大的范围。

我一直想知道在我们的代码中我们应该达到什么样的理想值。一些业内专家建议40-50的范围。但这纯粹是一种选择，没有任何具体原因。

我遇到了以下链接，但他们没有提出任何标准。

• Code Metrics – Maintainability Index
• Maintainability Index Range and Meaning

Answer 1

这个问题没有正确的答案。还有不少＆＃34;它取决于＆＃34;的问题：

• 有些方法很复杂，但不难维护。一个例子是Automapper配置，有很多相对简单的lambda。每个都是单独阅读，他们非常流利。他们可能会得分几乎变成红色，但他们没事。我喜欢在一大堆单独的方法上使用长的Automapper配置。
• 较旧版本的Metrics（我看到你标记为visual-studio-2010）特别容易受到Lambda表达式，委托和其他生成代码的项目的影响。 2013变体处理这些变得更好，2015变体（至少在IDE中）取决于Roslyn并且真正适用于您的代码..
• 具有错误名称的代码比具有良好代码的代码更难阅读，可维护性指数无法考虑这种可读性。
• 代码的布局也可以帮助或破坏代码的可读性。有没有试过阅读Minified的Javascript？这些将获得完全相同的可维护性指数得分！

除此之外，Visual Studio的标准阈值非常宽松。我记得Visual Studio团队的某个人引用过于严密的设置会标记太多普通客户的橙色或红色代码，让人讨厌这个工具，所以使用了一个稍微宽容的设置。这就是为什么许多拥有相当不错的代码库的人倾向于使用更严格的数字。

Metrics Codelens add-on or Visual studio 2013 Ultimate显示更好的标准分数：

使用60-100表示​​绿色。

您提出的正确设置是什么...... well it can be anything between 0 and 100, as that's the range the maintainability index floats between since they re-calibrated it。

任何超过20的东西都不是太糟糕，60以上的东西都不错。并且您肯定会有例外情况，即进一步分解并不会增加可读性，只会模糊代码的意图。因此，如果你想要更好的东西，也许可以选择Codelens使用的东西，但是不要打开一条全面的规则，说所有代码应至少为80 ，所有开发人员都会讨厌你，它不会像你希望的那样富有成效:)。