可维护性指标
我发现可维护性指数 (MI) 的建议值如下：
- 85 及以上：可维护性良好
- 65-85：可维护性中等
- 65 及以下< /strong>：确实很难维护 糟糕的代码片段（大的、未注释的、 非结构化）MI值可以是 甚至是负值
这些值是否取决于技术？ 例如，值 70 对于大型机来说很好，但对于 Java 来说很难维护吗？
可以使用独立于技术的相同标准吗？
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?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
这是解释维修性指标值的含义。
很快，这个值就会
在 0 到 100 之间缩放。
很容易看出，这个度量可以用于任何过程语言。
This is an explanation about meaning of maintainability index value.
Shortly this is
scaled between 0 and 100.
As it's easy to see, this metric can be used for any procedural language.
65 和 85 阈值来自介绍可维护性指数的原始论文 1992/1994 年。
Visual Studio 稍微调整了指标（乘以 100/171）以使其适合 1-100 的范围。 Visual Studio 使用 10 和20 作为阈值。
一般来说，我不会太认真地对待这个指标及其阈值：另请参阅我的博客文章“使用可维护性指数之前请三思。"
The 65 and 85 thresholds come from the original paper introducing the Maintainability Index in 1992/1994.
Visual Studio has slightly adjusted the metric (mutiplying by 100/171) to make it fit to a 1-100 scale. Visual Studio uses 10 and 20 as thresholds.
In general I would not take this metric and its thresholds too seriously: See also my blog post "Think Twice Before Using the Maintainability Index."
可维护性指数是一个经验公式。 它是基于观察和适应构建的模型。 如果您搜索更多细节，会发现该方程必须针对特定语言进行校准。 SEI的版本针对Pascal和C进行了校准，并使用了一堆程序，平均50KLOC，由惠普维护。
Visual Studio版本的校准与SEI版本相同，但增加了将域限制为0到100。
The Maintainability Index is a empirical formula. It is, was constructed a model based in observation and adaptation. If you search for more detail, will discover that the equation have to be cabibrated for a specific language. The version of SEI is calibrated for Pascal and C, and used a bunch of programs, average 50KLOC, maintained by Hewlett-Packard.
The calibration of Visual Studio version is the same of SEI version, but was padronized to restrict the domain from 0 to 100.
我认为您无法用数字来说明开发人员维护一段代码的容易程度。
不同的人会根据经验、文化、阅读理解等，查看相同的代码并以自己的方式解释它。
话虽如此，不同技术的指标肯定会有所不同。 您正在研究完全不同的语法、约定、术语等。您如何量化低级大型机代码与 Java 或 C# 等高级语言之间的难度差异？
我认为指标对一件事有好处，而且只有一件事：指导方针。 就代码质量而言，我认为除了描述代码库之外，它们不应该用于任何其他用途。 它们不应该被用作难度或“神通能力”的决定因素。
I don't think you can put a number on how easy a piece of code will be for a developer to maintain.
Different people will look at the same code and interpret it in their own way, depending on experience, culture, reading comprehension, etc.
That being said, metrics would definitely be different across technologies. You're looking at completely different syntax, conventions, terminology, etc. How can you quantify the difficulty difference between low level mainframe code and a high level language like Java or C#?
I think metrics are good for one thing, and one thing only: guidelines. In terms of code quality, I don't think they should be used for anything other than describing a code base. They should not be used as a determining factor of difficulty or "grok-ability".
这取决于“可维护性指数”的计算方式。 在我看来，这不像是可以跨语言工作的东西，因为语言是如此不同。
对“每个函数的行数”进行简单比较似乎是合理的，但是当您尝试比较充满指针的 C 代码、充满模板的 C++ 代码、或带有 LINQ 查询的 C# 或带有 LINQ 查询的 Java 时，会发生什么？仿制药？
所有这些因素都会影响可维护性，但无法以任何有意义的跨语言方式进行衡量，因此如何比较两种语言之间的数字呢？
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?