问题标签 [code-metrics]

我正在阅读Gerard Meszaros 的xUnit 测试模式。

在其中一页上，他提到了一些软件指标：

虽然需要换行以将它们保持在 65 个字符，这使得这段代码看起来比实际更长，但它仍然是不必要的长。它包含 25 个可执行语句，包括初始化声明、6 行控制语句、4 行内嵌注释和 2 行声明测试方法——总共 37 行展开的源代码。

如果没有计算语句以找到这些指标，是否有人知道他是否使用特定工具来计算指标？

（如果您对计算类似指标的工具有任何建议，我正在寻找适用于 Java、Javascript 和 C++ 的工具）

谢谢！

特别是，我很想知道有多少行代码，但这跨越了许多文件。

我一直在使用 notepad++ 编写代码，并且对于每个文件，它确实显示行号，但当然我有空返回以使代码更具可读性。

有谁知道我可以准确获取实际代码行的插件或工具？

有没有好的代码测量工具可用？

我发现代码测量非常有用且有趣，但我认为仅使用测量工具就无法支付 1000 美元/年的费用。

我想可能有一个工具是/可以

• 开源软件
• 语言无关
• 独立于操作系统
• 测量来自不同类别的指标：LOC、没有空行的 LOC、功能数量......

在 Windows 窗体、C#、.NET 3.5、VS2008...

将 MenuStrip（或任何复杂的控件组）的代码及其子菜单项与我的表单的其余部分隔离的好方法是什么？

例如，当我有一个带有多个菜单的 MenuStrip 并且每个菜单都有多个菜单项时，这些菜单项都有点击事件，大量的代码被注入到 Form.Desinger.cs 文件和 Form.cs 中文件。这在技术上不会造成任何问题，但是将这么多东西都倾倒在一个地方（连同表单中的其他所有东西）只是感觉不对。

在我的整个项目上运行代码度量，该表单被标记为具有任何项目文件中最差的可维护性索引。通常，我不会太教条地注意代码度量工具的方向，但在这种情况下，我完全同意。

根据 Code Metrics，该表单违反了以下最佳实践：

1. 类耦合过多
2. 代码行太多
3. 整体可维护性低

将 MenuStrip 与表单的其余部分隔离的可能解决方案：

1. 将其填充到用户控件中
2. 其他想法？

有没有人找到 VS 2010 的 Metric Shader 类型插件？我在 VS 2008 中使用了一个非常好的插件，它是 Dev Express DXCore 的插件：

公制着色器

但它在 VS 2010 中不起作用。我发现它在重构时是一个非常方便的工具，并且在 2010 年非常喜欢它。

谢谢！

我主要对代码度量的案例研究感兴趣，将代码可读性与缺陷减少联系起来，证明认真对待圈复杂度或一些类似度量是合理的。维基百科有这个例子：

许多研究调查了圈复杂度与模块中包含的缺陷数量的相关性。大多数此类研究发现圈复杂度和缺陷之间存在很强的正相关关系：具有最高复杂度的模块往往也包含最多的缺陷。例如，度量监控软件供应商 Enerjy 于 2008 年进行的一项研究分析了开源 Java 应用程序的类别，并根据在其中发现错误的常见程度将它们分为两组。他们发现圈复杂度与其故障之间存在很强的相关性，综合复杂度为 11 的类的故障概率仅为 0.28，而复杂度为 74 的类则上升到 0.98。

这很好，但我希望知道是否有更多的研究（或者可能对其他指标进行类似的研究，例如 SLOC）。

我还在IBM 发现了一篇文章，它提倡监控 CC 值，但它缺乏显示 ROI 数据的案例研究支持。然后是关于“箭头代码”的 Coding Horror 文章，其中包含案例研究的摘要，但没有提供案例研究本身，也没有提供证明结论合理的实际数字：

研究表明程序的圈复杂度与其错误频率之间存在相关性。低圈复杂度有助于程序的可理解性，并表明它比更复杂的程序更容易以更低的风险进行修改。模块的圈复杂度也是其可测试性的有力指标。

当然，圈复杂度 (CC) 将有助于发现箭头代码，但我仍然需要显示 ROI 值的案例研究。例如，“组织 X 在方法/功能上的最大 CC 为 10，并在接下来的开发迭代中减少了 20% 的缺陷。”

没有这种数据，很难让管理层关心。谁能指点我一些艰苦的研究？即使只有一个也会有所帮助...

我想扩展 2010 年静态代码分析指标（主要是修复它，所以汇总是最大值而不是总和）。扩展点在哪里？它是某个地方的 MEF 组件吗？

我在我的一个项目上运行了代码度量计算，并且看到了项目中每个命名空间/类的结果。我希望看到功能级别的结果。即使过滤器仍然在类级别上工作。有没有办法做到这一点？例如，我想查看任何圈复杂度超过 10 的函数，或者超过 20 行的函数。谢谢！

-谢恩

我们正在记录我们的软件开发过程。对于技术人员来说，这很容易：迭代开发，内部里程碑每 4​​ 周一次，外部每 3 个月一次。

然而，这个练习的目的是用他们可以理解的方式为我们的项目管理揭示事物。具体来说，这些非技术经理需要他们能够理解的指标。

我非常了解我们的指标选项，并提出了一整套建议（满足要求和实际成本与预算成本是我最喜欢的两个）。但是，我们确实有一些老手参与其中，他们倾向于坚持使用 SLOC 等指标。

我理解 SLOC 的诱惑：对于非软件人员来说，它似乎很容易理解，而且它似乎是最接近物理事物的模拟物（就像在过去计算打孔卡一样！）。

那么问题来了：我如何向非技术人员解释 SLOC 的危险？

这里有一些具体的动机：我们在一个相当成熟的部署系统上工作，它背后有多年的历史。当我们添加功能时，SLOC 往往会保持大致水平甚至下降（重构会删除旧/死代码，新功能实际上只是对现有功能的调整等）。对于非程序员经理来说，开发项目中不增加的 SLOC 充其量是令人困惑的......

澄清以下最近的回答：请记住，我认为 SLOC 是衡量项目进度的糟糕指标。我并不是说这是一个不值得收集的数字。它需要广泛的上下文才能使用它做任何有用的事情，而大多数项目经理都没有这种上下文。

我刚刚下载了 NDepend 的试用版。我正在寻找的是一种有助于代码标准化的工具。不仅在大括号、空格、命名约定等方面，而且在凝聚力和复杂性方面。

是否有人使用它可以告诉我是否可以将凝聚力和复杂性整合到构建错误中（例如，如果复杂性大于 > n，则错误）？？？在我开始编写自己的 xml 阅读器来解析 NDepend 结果之前，我想知道这是否与该工具集成。

我知道 Visual Studio 2008 的某些版本具有这些指标，但 NDepened 似乎独立于 Visual Studio 版本。还有其他工具可以推荐吗？？？

谢谢！