生产项目中C#和Visual Studio的代码度量常规值

Question

这里有一些关于代码指标的问题，特别是关于目标值的这个问题。但我想知道的是，在实际生产项目中通常的情况是什么。也许只是我自己的问题，但我参与的每个项目好像都没有考虑过这些问题，所以当我运行 ReSharper Code Issues 或 Visual Studio Code Metrics 时，结果总是让我感到意外。

以下是我当前 Sharepoint 任务中的一些示例：

Maintainability | Cyclomatic cmplx. | Inher. depth | Class coupl. | LOC
67              | 6,712             | 7            | 569          | 21,649
68              | 3,192             | 7            | 442          | 11,873

那么，问题是，在实际应用中你通常看到什么值？除了最佳实践和最优值，通常会遇到哪些值？

- John-Philip

---

这是一个聚合，你应该挖掘每个类并逐个检查。在我看来，对于一个代码库“不仅仅是琐碎”的项目来说，查看总体数据并没有太多意义，它们只能给你一个快速的想法，告诉你代码库是真的好还是真的糟糕，但除此之外没有其他作用...PS 无论如何...问题是什么？ - mamoo

Answer 1

我假设这些数值是在装配级别上陈述的。如果是这样，那么在方法级别上，“圆形复杂度”和“代码行数”最有帮助。“继承深度”应该首先在类级别上看。“类耦合”在首先在方法级别上查看，然后在类级别上查看时提供更有用的反馈。

除了您提供的堆栈溢出链接提供的指南外，第二版《代码大全》对方法圆形复杂度的页面458有以下说明：

• 0-5 这个例程可能很好。
• 6-10 考虑简化程序的方式。
• 10+ 将程序的一部分拆分为第二个程序，并从第一个程序中调用它。

在“现实生活”项目中，可接受的情况可能取决于您正在使用的开发过程类型。如果团队正在实践TDD（测试驱动开发）并努力编写SOLID代码，则这些指标应接近最佳值。

如果是TAD（开发后测试）或者更甚的没有单元测试的代码，则预计所有指标都比最佳值高，因为具有更高的耦合性、更复杂的方法和类以及可能更普遍的继承。但无论如何编写代码，目标都应该是限制“糟糕”指标的情况。

- Matt

Answer 2

关于软件度量的基本误解在于它们被放入漂亮的报告中时就很有用。大多数人使用以下错误的过程：

1. 收集工具支持的任何度量标准。 2. 编写报告。 3. 将其与推荐值进行比较。 4. 开始寻找他们新获得答案可能解决的问题。

这是错误的、颠倒的并且毫无成效的。任何度量标准收集的正确方法是首先弄清楚“为什么”。您测量的原因是什么？回答了这个问题，您可以弄清楚要测量的内容，并且在了解了“为什么”和“什么”之后，您可以确定如何获取一些信息以指导进一步探究。

我见过对列出的度量标准的各种价值，老实说，在不同项目或环境中进行比较真的没有多少意义。您可以相当肯定地认为同一个团队将会生产出看起来像他们以前做过的东西。但是你不需要度量标准来弄清楚这一点。

您可以使用指标来查找需要调查的“热点”，但是如果您有质量问题，那么漏洞问题总会聚集在问题模块中，而去寻找它们几乎没有用。

现在，不要误解我的意思。我喜欢度量标准。我编写了多个脚本和工具来提取、可视化和进行各种花哨的操作，这些都是好玩的事情，甚至可能是有益的，但我并不确定后者。

- Torbjörn Gyllebring