Visual Studio 中的代码指标计算

发布于 2024-08-17 04:09:31 字数 96 浏览 5 评论 0原文

以下

  • 可维护性指数
  • 循环复杂度
  • 继承深度
  • 类耦合的代码度量计算的首选分数范围是多少

What is the prefered score range for the code metrics calculation for the following

  • Maintainability Index
  • Cyclomatic Complexity
  • Depth of Inheritance
  • class Coupling

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

陌生 2024-08-24 04:09:31

理论上的最佳值为:

  • 可维护性指数:100。数值越高,可维护性越好。
  • 圈复杂度: 1. 代码可以采用的不同路径的数量。
  • 继承深度: 1.继承树中该类定义之上的类定义数量,不包括接口。
  • 类耦合:0。该实体所依赖的其他实体的数量。

虽然可以做出一些一般性的陈述,但没有硬性规定的“好”范围。

  • 每个方法的圈复杂度较高表明该方法变得过于复杂。
  • 继承深度超过大约 3 或 4(您自己的类,而不是框架的)是一个麻烦的迹象,表明您可能不必要地表示并不真正属于您的软件领域的抽象关系。
  • 低级耦合通常更好,但有时是不可避免的。在可能的范围内,您绝对应该最小化命名空间之间的依赖关系,因为这里依赖关系的原因要少得多。

一个项目只能通过本质上不做任何事情并且毫无用处才能同时达到所有四个价值:不做任何事情并且不依赖任何东西的软件当然是可维护的,但不能很好地利用客户的资金。

因此,所有的复杂性都是一种权衡:额外的所谓的固有复杂性将更多的复杂性编码到程序中,从而允许它扩展功能集。您希望避免的是由于实施不当或有缺陷而导致的意外复杂性。

The theoretically optimal values are:

  • Maintainability index: 100. Higher values indicate better maintainability.
  • Cyclomatic complexity: 1. The number of different paths that code can take.
  • Depth of inheritance: 1. The number of class definitions above this one in the inheritance tree, not including interfaces.
  • Class coupling: 0. Number of other entities this entity is dependent on.

There are no hard and fast "good" ranges, though it's possible to make some general statements.

  • Having high per-method cyclomatic complexity suggests a method is getting too complicated.
  • Having an inheritance depth more than about 3 or 4 (of your own classes, not the framework's) is a trouble sign that you may be unnecessarily representing abstract relationships that aren't really in your software's domain.
  • Low class coupling is in general better, but sometimes it's unavoidable. To the extent possible, you should definitely minimize the dependency between namespaces, since there's much less reason for dependencies here.

A project could only reach all four values simultaneously by essentially doing nothing and being useless: software that does nothing and depends on nothing is certainly maintainable, but not a very good use of client dollars.

Therefore, all complexity is a tradeoff: additional so-called inherent complexity encodes more sophistication into the program, allowing it to expand the feature set. What you would like to avoid is accidental complexity introduced by a poor or deficient implementation.

荒人说梦 2024-08-24 04:09:31

在过度依赖它(或完全依赖它)之前,请检查以下页面,其中提供了有关如何计算指标的更多详细信息:

https://avandeursen.com/2014/08/29/think-twice-before-using-the-maintainability-index/ VS 的可维护性指数是一个未经充分验证的指标组合

,它本身依赖于一个指标(圈复杂度),该指标已被证明与代码可理解性不相关(因此与可维护性不相关)。请参阅 Scalabrino 等人的“自动评估代码可理解性:我们还有多远?”。
https://shape-of-code.com/?s=cyclomatic+complexity

此外,该指标中使用的常量和函数选择尚未在 C# 或 VB 代码上进行校准,这进一步使其毫无用处。

(这通过指出甚至不应该问原始问题来解决原始问题。)

Before relying too heavily on it (or relying on it at all), check the following page, which gives more detail on how the metric is computed:

https://avandeursen.com/2014/08/29/think-twice-before-using-the-maintainability-index/

VS' Maintainability Index is a poorly-validated combination of metrics, which itself relies a metric (cyclomatic complexity) that has been shown to not correlate with code understandability (which would therefore not correlate with maintainability). See "Automatically Assessing Code Understandability: How Far Are We?", by Scalabrino et al.
and https://shape-of-code.com/?s=cyclomatic+complexity

Furthermore, the constants and function choices used in this metric have not been calibrated on C# or VB code, which further makes it useless.

(This addresses the original question by pointing out that the original question should not even be asked.)

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文