我遇到了维护性指数（MI）的推荐值，如下所示：
这些值是否依赖于技术？例如，对于大型机来说，值是70，但对于Java来说难以维护吗？
可以使用与技术无关的相同尺度吗？
答案 0 :(得分：12)
这是an explanation关于可维护性指标值的含义。
很快这是
MI = 171 - 5.2*ln(Halstead Volume) - 0.23*(Cyclomatic Complexity) - 16.2*ln(Lines of Code)
在0到100之间缩放。
由于很容易看到，这个指标可以用于任何程序语言。
答案 1 :(得分：6)
65和85门槛来自original paper在1992/1994年引入可维护性指数。
Visual Studio略微调整了指标（多次使用100/171），使其适合1-100的比例。 Visual Studio使用10 and 20 as thresholds。
一般情况下，我不会过分重视此指标及其阈值：另请参阅我的博文“Think Twice Before Using the Maintainability Index。”
答案 2 :(得分：3)
可维护性指数是一个经验公式。它是，建立了一个基于观察和适应的模型。如果您搜索更多细节，将发现必须针对特定语言对等式进行校准。 SEI的版本针对Pascal和C进行了校准，并使用了一系列程序，平均为50KLOC，由Hewlett-Packard维护。
Visual Studio版本的校准与SEI版本相同，但经过padronized将域限制为0到100。
答案 3 :(得分：2)
我认为你不能说一个代码对于开发人员来说是多么容易维护。
不同的人会根据经验，文化，阅读理解等来查看相同的代码并以自己的方式解释它。
话虽如此，各种技术的指标绝对会有所不同。您正在研究完全不同的语法，约定，术语等。您如何量化低级大型机代码与Java或C＃等高级语言之间的难度差异？
我认为指标对一件事情有好处，而且只有一件事：指引。在代码质量方面，我不认为它们应该用于描述代码库以外的任何其他内容。它们不应被用作困难或“grok-ability”的决定因素。
答案 4 :(得分：0)
这取决于如何计算“可维护性指数”。对我而言，这似乎并不像是因为语言如此不同而在语言中起作用。
对“每个函数的行数”进行简单比较似乎是合理的，但是当您尝试比较充满指针的C代码，或者充满模板的C ++代码或带有LINQ查询的C＃时，会发生什么？还是带有泛型的Java？ 所有这些都会影响可维护性，但无法以任何有意义的跨语言方式进行衡量，那么如何比较两种语言之间的数字呢？