生产项目的代码指标（C#、Visual Studio）的常用值

Question

这里有一些关于代码度量的问题，尤其是关于目标值的this one。我正在寻找的是在现实生活中的制作项目中“常见”的东西。也许只有我一个人，但我参与的任何项目都没有考虑过这些事情，所以当我运行 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

那么，问题是，您通常在“野外”看到什么价值观？除了最优值和最佳实践，通常会遇到哪些值？

Answer 1

关于软件指标的基本误解是，它们在放入漂亮的报告时很有用。

大多数人使用以下有缺陷的流程：

• 收集他们的工具支持的所有指标
• 编制报告
• 将其与推荐值进行比较
• 开始寻找他们新找到的答案可能解决的问题

这是错误的、倒退的、在很多层面上都会适得其反，甚至都不好笑。收集任何指标的正确方法是首先找出为什么。你测量的原因是什么？有了这个答案，您可能会弄清楚什么要衡量，并且鉴于您知道自己的为什么和什么，您可以弄清楚如何 em> 以获得一些可能指导进一步调查的信息。

我已经看到您列出的指标的范围很广，老实说，跨项目或环境进行比较确实没有多大意义。

您可以相当肯定，同一个团队会生产出与他们之前所做的相似的东西。但你不需要指标来解决这个问题。

您可以使用这些指标来查找“热点”进行调查，但如果您有质量问题，那么无论如何，错误都会聚集在有问题的模块中，而寻找它们几乎是无用的。

现在不要误会我的意思。我喜欢指标。我编写了多个脚本和工具来提取可视化并用它们做各种花哨的东西，这一切都很有趣，甚至可能是有益的，不过我不太确定后者。

Answer 2

我假设这些值是在汇编级别。如果是这样，Cyclomatic Complexity 和 Lines of Code 在方法级别上最有帮助。 继承深度应该主要在类级别上查看。 类耦合在首先查看方法级别然后查看类级别时会提供更有用的反馈。

除了您包含的stack overflow link 中提供的指南之外，Code Complete 第 2 版还谈到了方法 Cyclomatic Complexity，第 458 页：

• 0-5 例程可能没问题。
• 6-10 开始思考简化例程的方法。
• 10+ 将例程的一部分分解为第二个例程并从第一个例程中调用它

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

如果 TAD（开发后测试），或者更重要的是，没有单元测试的代码，那么期望所有指标都高于最佳指标，因为可能有更多的耦合、更复杂的方法和类，并且可能更多产继承可能会升高。尽管如此，目标应该是限制具有“不良”指标的情况，无论代码是如何开发的。