我主要对代码指标的案例研究感兴趣，将代码可读性与缺陷减少相关联，这证明了采取严重的圈复杂度或某些类似指标的合理性。维基百科有这个例子：
许多研究已经调查过 圈复杂度与...的相关性 a中包含的缺陷数量 模块。大多数此类研究发现了 之间有很强的正相关 圈复杂性和缺陷： 最高的模块 复杂性往往也包含 大多数缺陷。例如，2008年 通过公制监测软件进行研究 供应商Enerjy分析了 开源Java应用程序和 根据它们将它们分成两组 发现故障的常见程度 他们。他们发现了强相关性 在圈复杂度和 他们的缺点，与一个班级 结合11的复杂性 容易出错的概率 只有0.28，上升到0.98级 复杂度为74。
这很好，但我希望知道是否有更多的研究（或者其他指标的类似研究，例如SLOC）。
我还发现article at IBM可以促进对CC值的监控，但缺乏案例研究支持来显示ROI数据。然后是Coding Horror article on "arrow code"，其中提供了案例研究的摘要，但不提供案例研究本身，也不提供证明结论的实际数字：
研究表明a之间存在相关性 程序的圈复杂度和 它的错误频率。低圈 复杂性有助于一个程序 可理解性并表明它是 能够以较低的风险进行修改 而不是一个更复杂的计划。一个 模块的圈复杂度也是 它是可测试性的有力指标。
当然，圈复杂度（CC）将有助于发现箭头代码，但我仍然需要显示ROI值的案例研究。例如，“组织X在方法/函数中包含最大CC为10，在以下开发迭代中减少了20％的缺陷。”
如果没有这类数据，很难让管理层得到关注。谁能指点我一些艰苦的学习？即使只有一个会帮助......
答案 0 :(得分：1)
“......我仍然需要显示投资回报率值的案例研究。”
为什么投资回报率如此之高？
这就是原因。
个人程序员的工作效率至少有一个，有时是两个数量级。
个人差异胜过您可能正在寻找的任何其他影响。你不能做一个“头对头”，“苹果对苹果”的比较。当您使用不同的技术（即不同的复杂度阈值）比较两个类似的团队时，您会发现个别的性能差异只是主导数据而且几乎所有内容都是噪声。
“如果没有这类数据，很难让管理层得到关注。”
如果管理层不关心质量，那么你就会遇到很大问题。投资回报率不会影响管理层改变环境。
您必须在自己的组织中使用自己的代码运行自己的实验。
收集Cyclomatic复杂性，缺陷率，问题单，崩溃，任何你可以。尝试将复杂性与其他不良指标相关联。争论性的经理总是可以通过指出团队成员之间的个体差异而获胜。
在真实组织中使用真实数据。这是你能做的最好的事情。这不是“一些研究”或“一些白皮书”这是你的实际组织。
答案 1 :(得分：1)
以下是面向对象指标的一些内容：
答案 2 :(得分：0)
在这种情况下，您可以从original article获得比维基百科更多的内容。他的technical paper关于数据收集方式如何在结论中显示出95％的置信水平。
您是对的，这不会直接提供投资回报率信息。至少对于这项研究来说，这将是相当困难的 - 例如，他们使用开源项目来获取他们的培训数据，而开源项目的实际成本通常难以估算，更不用说衡量标准了。与此同时，他们确实使用了我认为至少是真实ROI数据的合理代理：他们通过源控制系统搜索他们的每个“培训”项目，寻找与修复相关的签到然后，他们使用朴素贝叶斯算法来查找他们使用的度量与代码中已识别的问题之间的相关性。虽然毫无疑问至少会有一些改进，但在我看来，这些结果至少应该意味着什么。
同样值得注意的是，进行此项研究的人员在大量开源项目中保持运行index。如果您想要更多的固体数据，可以根据某些项目的源控制日志检查其索引，您可以使用他们的数据来提供更多直接ROI类型结果。但需要注意的是：他们的索引基于相当多的源代码指标，不只是圈复杂度，所以我不确定它究竟会告诉CC多少关于CC而不是其他指标他们看着。