13

I have come across the recommended values for a Maintainability Index (MI) as follows:

  • 85 and more: good maintainability
  • 65-85: moderate maintainability
  • 65 and below: difficult to maintain with really bad pieces of code (big, uncommented, unstructured) the MI value can be even negative

Are these values are dependent on technology? For example, is a value of 70 good for Mainframes but difficult to maintain for Java?

Can use same yardstick independent of technologies?

4

5 回答 5

14

这是关于可维护性指标值含义的解释。

不久这是 

MI = 171 - 5.2*ln(Halstead Volume) - 0.23*(Cyclomatic Complexity) - 16.2*ln(Lines of Code)

在 0 到 100 之间缩放。

很容易看出，该指标可用于任何程序语言。

于 2009-12-07T11:17:34.953 回答
9

65 和 85 阈值来自于 1992/1994 年介绍可维护性指数的原始论文。

Visual Studio 略微调整了指标（乘以 100/171）以使其适合 1-100 的比例。Visual Studio 使用10 和 20 作为阈值。

一般来说，我不会太认真地对待这个指标及其阈值：另请参阅我的博客文章“在使用可维护性指数之前三思”。

于 2014-09-11T16:47:42.607 回答
3

可维护性指数是一个经验公式。它是基于观察和适应构建的模型。如果您搜索更多细节，会发现必须针对特定语言对方程式进行校准。SEI 的版本针对 Pascal 和 C 进行了校准，并使用了一堆程序，平均 50KLOC，由 Hewlett-Packard 维护。

Visual Studio 版本的校准与 SEI 版本相同，但被修改为将域限制为 0 到 100。

于 2014-04-12T19:58:24.090 回答
2

我认为您无法对开发人员维护一段代码的难易程度给出一个数字。

不同的人会根据经验、文化、阅读理解等来查看相同的代码并以自己的方式解释它。

话虽如此，不同技术的指标肯定会有所不同。您正在查看完全不同的语法、约定、术语等。您如何量化低级大型机代码和高级语言（如 Java 或 C#）之间的难度差异？

我认为指标对一件事有好处，而且只有一件事：指导方针。就代码质量而言，我认为它们不应该用于描述代码库以外的任何事情。它们不应该被用作难度或“grok-ability”的决定因素。

于 2009-11-10T15:12:54.107 回答
0

It depends how the "Maintainability Index" is calculated. This doesn't seem to me like something which would work across languages simply because languages are so different.

It might seem reasonable to do a simple compare of "number of lines per function", but what happens when you try and compare C code which is full of pointers, or C++ code full of templates, or C# with LINQ queries, or Java with generics?
All of those things affect maintainability but can't be measured in any meaningful cross-language way, so how can you ever compare numbers between 2 languages?

于 2009-02-27T03:31:07.213 回答