这里有一些关于代码指标的问题,尤其是关于目标值的this one。我正在寻找的是现实生活中的生产项目中的“通常情况”。也许只是我一个人,但是我从事的任何项目都没有想到这些事情,因此,当我运行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
因此,问题是,您通常会在野外看到哪些价值观?除了最佳值和最佳实践,通常会遇到什么值?
我假设这些值是在组装级别上。如果是这样,循环复杂度和代码行在方法级别上最有帮助。 继承深度应该首先在类级别上查看。首先在方法级别然后在类级别查看时,类耦合提供更多有用的反馈。
除了您所包含的stack overflow link中提供的准则之外,Code Complete 2nd Edition还对方法Cyclomatic Complexity,第458页说了这句话:
- 0-5例程可能很好。
- 6-10开始考虑简化例程的方法。
- 10+将例程的一部分分解为第二个例程,并从第一个例程中调用它
在“现实生活”项目中,可接受的内容可能取决于您使用的开发过程的类型。如果团队正在实践TDD(测试驱动开发)并努力编写SOLID代码,则这些指标应接近最佳值。
如果是TAD(开发后测试),或者甚至是没有单元测试的代码,那么由于具有更多耦合,更复杂的方法和类以及更丰富的继承的可能性,期望所有指标都高于最佳指标。可能会升高。尽管如此,目标还是应该限制具有“不良”指标的情况,而不管代码是如何开发的。
关于软件指标的基本误解是,当将它们添加到漂亮的报告中时,它们很有用。
大多数人使用以下有缺陷的过程:
这是错误的,在许多层面上都是倒退和适得其反,甚至不好笑。收集任何指标的正确方法是首先弄清楚为什么。你测量的原因是什么?回答了这个问题,您可能会想出what进行测量,并且只要知道您的why和what,您就可以弄清楚how来获取一些信息,以指导进一步的研究。
我已经看到了您列出的指标的各种值,并且老实说,在整个项目或环境中,比较的确没有太大意义。
您可以肯定地确定,同一支团队将产生看起来像他们之前所做的东西。但是您不需要度量就可以解决这一问题。
您可以使用指标来查找要调查的“热点”,但是如果您有质量问题,无论如何,错误都会聚集在有问题的模块中,而寻找它们几乎是没有用的。
现在不要误会我的意思。我喜欢指标。我已经编写了多个脚本和工具来提取可视化内容并使用它们来做各种花哨的东西,这一切都很好玩,甚至可能是有益的,尽管我以后不太确定。