生产项目的代码度量标准(C#,Visual Studio)的常用值

Question

有关于代码度量的一些问题在这里,尤其是这一个目标价值.我正在寻找的是现实生产项目中的"常用".也许只是我,但是没有任何项目我曾经记住这些事情,所以当我运行ReSharper代码问题或Visual Studio代码指标时,我似乎是第一个 - 所以价值总是让我感到惊讶.

我当前的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

我假设这些值是在装配水平上.如果是这样,Cyclomatic Complexity和Code of Code对方法级别最有帮助.应该主要在类级别上查看继承深度.在首先查看方法级别然后在类级别上查找类耦合时,它会提供更有用的反馈.

除了您提供的堆栈溢出链接中提供的指南之外,Code Complete 2nd Edition还有关于方法Cyclomatic Complexity,第458页的说明:

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

在"现实生活"项目中,可接受的可能取决于您正在使用的开发过程的类型.如果团队正在练习TDD(测试驱动开发)并努力编写SOLID代码,那么这些指标应接近最佳值.

如果TAD(开发后测试)或者甚至更多的是没有单元测试的代码,那么期望所有度量都高于最优,因为具有更多耦合,更复杂的方法和类的可能性,以及可能更多的继承可能是升高.尽管如此,目标应该是限制具有"坏"指标的情况,无论代码是如何开发的.

Answer 2

关于软件度量的根本误解是它们在被放入漂亮的报告中时非常有用.

大多数人使用以下有缺陷的过程:

• 收集他们的工具支持的任何指标
• 编译报告
• 将其与建议值进行比较
• 开始寻找他们新发现的答案可能解决的问题

这是错误的,在许多层面上都是倒退和适得其反的,甚至都不好笑.任何指标收集的正确方法是首先弄清楚原因.你测量的原因是什么？与回答你可能会想出什么来衡量和考虑到你知道你为什么和怎样你能弄清楚如何获得可能引导进一步询问一些信息.

我已经看到了您列出的指标的广泛价值,并且在项目或环境中保持诚实,这些比较确实没有多大意义.

你可以相当肯定,同一个团队会产生看起来像他们以前做过的东西.但是你不需要指标来解决这个问题.

您可以使用指标来查找要调查的"热点",但如果您遇到质量问题,则无论如何都会在有问题的模块中聚集错误,并且寻找它们几乎是无用的.

现在不要误会我的意思.我喜欢指标.我已经编写了多个脚本和工具来提取可视化并用它们做各种奇特的东西,这一切都很有趣,甚至可能是有益的,但我不是那么晚.