代码度量有什么魅力？ [关闭]

Question

就目前而言，这个问题不适合我们的问答形式。 我们希望答案得到事实、参考或专业知识的支持，但这个问题可能会引起辩论、争论、投票或扩展讨论。 如果您认为此问题可以改进并可能重新打开，请访问帮助中心以获取指导。

8 年前关闭。

我最近在 SO 上看到了许多与“代码指标”相关的问题，我想知道它的魅力是什么？ 下面是一些最近的例子：

• 什么代码指标让你相信提供的代码是糟糕的
• 当代码行数成为一个有用的指标时
• 编写质量测试

不过，在我看来，没有任何指标可以替代代码审查：

• 某些指标有时可能表明需要审查的地方，以及
• 短期内指标的根本变化可能表明需要审查的地方

但是我想不出一个指标本身总是指示“好”或“坏”代码 - 对于测量无法看到的事情，总是有例外和原因。

是否可以从我忽略的代码指标中获得一些神奇的见解？ 懒惰的程序员/经理是否在寻找不阅读代码的借口？ 人们是否面临巨大的遗留代码库并正在寻找起点？ 这是怎么回事？

注意：我在答案和评论中就特定线程提出了其中一些问题，但没有得到答复，所以我想我应该向社区询问一般情况，因为我可能遗漏了一些东西。 运行度量批处理作业并且实际上不必再次阅读其他人的代码（或我自己的代码）会很好，我只是认为这不实用！

编辑：我对所讨论的大多数指标（如果不是全部）都很熟悉，我只是没有孤立地或任意的质量标准来看待它们的意义。

Answer 1

这个帖子中的答案有点奇怪，因为他们谈到：

• “团队”，例如上述指标的“唯一受益者”；
• “指标”，就像它们本身意味着什么一样。

1/ 指标不是针对一个群体，而是针对三个群体：

• 开发人员：他们关注关于代码静态分析的瞬时静态代码指标（圈复杂度、评论质量、行数……）
• 项目负责人：他们关注来自单元测试、代码覆盖率、持续集成测试的每日实时代码指标
• 业务发起人（他们总是被遗忘，但他们是利益相关者，为开发付出代价的人）：他们关注关于架构设计、安全性、依赖关系的每周全球代码指标......

当然，所有三个群体都可以观察和分析所有这些指标，但每种指标都旨在为每个特定群体更好地使用。

2/ 指标本身代表代码的快照，这意味着……什么都没有！

正是这些指标的组合以及这些不同分析级别的组合可能表明代码“好”或“坏”，但更重要的是，这些指标的趋势是重要的。

重复这些指标会带来真正的附加值，因为它们将帮助业务经理/项目负责人/开发人员在不同的可能代码修复中确定优先级

---

换句话说，您关于“指标的魅力”的问题可能指的是以下之间的区别：

• “漂亮”的代码（尽管这总是在旁观者编码器的眼中）
• “好”代码（有效，并且可以证明它有效）

因此，例如，圈复杂度为 9 的函数可以被定义为“美丽的”，而不是圈复杂度为 42 的一个长而复杂的函数。

但是，如果：

• 后一个函数具有稳定的复杂度，结合95% 的代码覆盖率，
• 而前者的复杂性越来越高，加上覆盖率... 0%，

有人可能会争辩说：

• 后者代表一个“好”的代码（它有效，稳定，如果需要更改，可以检查修改后是否仍然有效），
• 前者是“坏”代码（它仍然需要添加一些案例和条件来覆盖它必须做的所有事情，并且没有简单的方法可以进行一些回归测试）

---

所以，总结一下：

一个单独的指标，它本身总是表明 [...]

: 不多，除了代码可能更“漂亮”，这本身并不意味着很多......

是否可以从我忽略的代码指标中获得一些神奇的见解？

只有指标的组合和趋势才能提供您所追求的真正“神奇的洞察力”。

Answer 2

几个月前，我有一个项目，我作为一个人的工作来衡量圈复杂度。 那是我第一次接触这些指标。

我得到的第一份报告令人震惊。 我几乎所有的功能都没有通过测试，即使是（恕我直言）非常简单的功能。 我通过将逻辑子任务移动到子例程中来解决复杂性问题，即使它们只被调用过一次。

对于另一半例程，我作为一名程序员的骄傲开始发挥作用，我试图以他们做同样的方式重写它们，只是更简单，更易读。 这很有效，我能够最大限度地降低客户的复杂性阈值。

最后，我几乎总能想出更好的解决方案和更简洁的代码。 性能没有受到影响（相信我 - 我对此很偏执，我经常检查编译器输出的反汇编）。

我认为如果您将指标用作改进代码的理由/动机，那么指标是一件好事。 不过，重要的是要知道何时停止并要求违反度量标准。

指标是指南和帮助，而不是目的本身。

Answer 3

我用过的最好的指标是CRAP 分数。

基本上，它是一种将加权圈复杂度与自动化测试覆盖率进行比较的算法。 该算法如下所示： CRAP(m) = comp(m)^2 * (1 – cov(m)/100)^3 + comp(m)其中 comp(m) 是方法 m 的圈复杂度，cov (m) 是自动化测试提供的测试代码覆盖率。

前面提到的文章的作者（请去阅读它......这很值得你花时间）建议最高 CRAP 分数为 30，按以下方式分解：

Method’s Cyclomatic Complexity        % of coverage required to be
                                      below CRAPpy threshold
------------------------------        --------------------------------
0 – 5                                   0%
10                                     42%
15                                     57%
20                                     71%
25                                     80%
30                                    100%
31+                                   No amount of testing will keep methods
                                      this complex out of CRAP territory.

正如您很快看到的，该指标奖励编写不复杂的代码以及良好的测试覆盖率（如果您正在编写单元测试，并且您应该这样做，并且没有测量覆盖率......好吧，您可能会喜欢随地吐痰同样）。 ;-)

对于我的大多数开发团队，我真的很努力地使 CRAP 分数低于 8，但如果他们有充分的理由证明增加的复杂性是可以接受的，只要他们通过足够的测试覆盖了复杂性。 （编写复杂的代码总是很难测试......这个指标的一种隐藏的好处）。

大多数人最初发现很难编写通过 CRAP 分数的代码。 但随着时间的推移，他们编写了更好的代码，问题更少的代码，以及更容易调试的代码。 在任何指标中，这是关注最少且收益最大的指标。

Answer 4

对我来说，识别不良代码的最重要的指标是圈复杂度。 我的项目中几乎所有方法都低于 CC 10，并且在 CC 超过 30 的遗留方法中总是会发现错误。高 CC 通常表示：

• 匆忙编写的代码（即没有时间找到一个优雅的解决方案，而不是因为问题需要一个复杂的解决方案）
• 未经测试的代码（没有人为这样的野兽编写测试）
• 被多次修补和修复的代码（即充斥着 ifs 和 todo 注释）
• 重构的主要目标

Answer 5

好的代码审查不能代替好的静态分析工具，当然不能代替好的单元测试，现在的单元测试没有一套验收测试是不行的……

代码度量是另一种放入工具箱的工具，它们本身并不是解决方案，它们只是一种可以适当使用的工具（当然还有工具箱中的所有其他工具！）。

Answer 6

人们被理解和描述代码的机械方式的想法所吸引。 如果为真，请考虑对效率和生产力的影响！

我同意“代码质量”的衡量标准与“好散文”的衡量标准一样合理。 然而，这并不意味着指标没有用，只是可能被误用了。

例如，某些指标的极值指向可能存在的问题。 一个 1000 行长的方法可能无法维护。 与具有大量测试的类似代码相比，具有零单元测试代码覆盖率的代码可能有更多的错误。 在发布之前添加到项目中的不是第三方库的代码的大跃进可能会引起额外的关注。

我认为如果我们使用指标作为建议——一个危险信号——也许它们会很有用。 问题是当人们开始以 SLOC 衡量生产力或以测试线百分比衡量质量时。

Answer 7

我的高度主观意见是，代码度量表达了一种不可抗拒的制度魅力，即能够量化本质上无法量化的事物。

在某种程度上，至少在心理上是有道理的——你怎么能对你无法评估或理解的事情做出决定？ 最终，当然，除非您对这个主题很了解（并且至少与您要评估的内容一样好）或询问知识渊博的人，否则您无法评估质量，这当然只会把问题放回去一步。

从这个意义上说，也许一个合理的类比是通过 SAT 分数来评估大学入学者，这是不公平的，并且错过了所有微妙之处，但如果您需要量化，您就必须做一些事情。

并不是说我认为这是一个很好的衡量标准，只是我可以看到它的本质上的不可抗拒性。 而且，正如您所指出的，可能有一些合理的指标（大量 500 多种行方法，高复杂性 - 可能很糟糕）。 不过，我从来没有去过一个买这个的地方。

Answer 8

我相信一个代码指标。

我正在开发一个大系统。 当一个新的需求出现在我面前时，我开始着手编写代码。 当我完成并解决了错误后，我将其检查到版本控制系统中。 该系统做了一个差异，并计算出我所做的所有更改。

这个数字越小越好。

Answer 9

指标和自动化测试并不意味着要替代完整的代码审查。

他们只是加快速度。 使用自动检查器，很容易查看您忘记遵循哪些约定，您正在使用指定的包和方法等。您可以在不占用其他人时间的情况下查看您可以修复的内容。

经理们也喜欢衡量他们，因为他们觉得他们得到了一个关于生产力的准确数字（尽管通常情况并非如此）并且他们应该能够更好地与人打交道。

Answer 10

测量仅在以下情况下有用：

• 团队开发了它们
• 团队同意他们
• 它们被用于识别特定区域

一般来说，任何不适合的指标都会受到团队优化的影响。 您想测量代码行数吗？ 天哪，看看他们能写多少！ 你想测量代码覆盖率，天哪，看着我覆盖那些代码！

我认为指标对于识别趋势很有用，事实上，我已经看到了一些有用的指标，例如绘制何时构建中断、代码流失（整个项目中更改的代码行数）等。 但是，如果团队没有提出这些建议，或者他们不同意或不理解这些建议，那么您很可能处于受伤的世界中。

Answer 11

这是来自stan4j 的一些复杂性指标。

一个eclipse类结构分析工具。

我喜欢这个工具和指标。 我将指标视为统计数据、指标、警告消息。 有时因为某些方法或某些类确实有一些复杂的逻辑使它们变得复杂，应该做的是关注它们，检查它们，看看是否需要重构它们或仔细检查它们，由于通常他们很容易出错。 我也用它作为分析工具来学习源代码，因为我喜欢从复杂到简单的学习。实际上它包括一些其他指标，例如 Robert C. Martin Metrics、Chidamber & Kemerer Metrics、Count Metrics 但我最喜欢这个

复杂性指标

圈复杂度指标

圈复杂度 (CC) 方法的圈复杂度是方法的控制流图中的决策点数量加 1。 决策点出现在 if/for/while 语句、case/catch 子句和类似的源代码元素中，其中控制流不仅仅是线性的。 由单个（源代码）语句引入的（字节代码）决策点的数量可能会有所不同，这取决于例如布尔表达式的复杂性。 方法的圈复杂度值越高，测试方法控制流图的所有分支所需的测试用例就越多。

平均圈复杂度圈复杂度指标在应用程序、库、包树或包的所有方法上的平均值。

Fat Metrics工件的 Fat 度量是工件的适当依赖图中的边数。 依赖图类型取决于度量变体和选择的工件：

Fat应用程序、库或包树的 Fat 度量是其子树依赖关系图的边数。 该图包含包树层次结构中所有工件的子项，因此也包括叶包。 （要在组合视图中查看适当的图形，必须禁用 Structure Explorer 的 Flat Packages 切换。如果所选工件是库，则必须启用 Show Libraries 切换，否则必须禁用。）

包的 Fat 度量是其单元依赖关系图的边数。 此图包含包的所有顶级类。

一个类的 Fat 度量是其成员图的边数。 该图包含该类的所有字段、方法和成员类。 （此图和 Fat 值仅在使用详细级别成员而非类执行代码分析时可用。）

Fat for Library Dependencies (Fat - Libraries)应用程序的库依赖 Fat 度量是其库依赖关系图的边数。 此图包含应用程序的所有库。 （要在 Composition View 中查看适当的图形，必须启用 Structure Explorer 的 Show Libraries 切换。）

Fat for Flat Package Dependencies (Fat - Packages)应用程序的 Fat for Flat Package Dependencies 指标是其扁平包依赖关系图的边数。 此图包含应用程序的所有包。 （要在 Composition View 中查看适当的图形，必须启用 Structure Explorer 的 Flat Packages 开关，并且必须禁用 Show Libraries 开关。）

库的扁平包依赖关系指标是其扁平包依赖关系图的边数。 该图包含库的所有包。 （要在 Composition View 中查看适当的图形，必须启用 Structure Explorer 的 Flat Packages 和 Show Libraries 切换。）

Fat 顶级类依赖关系（Fat - 单元）应用程序或库的顶级类依赖关系 Fat 度量是其单元依赖关系图的边数。 该图包含应用程序或库的所有顶级类。 （对于合理的应用程序，它太大而无法可视化，因此无法在组合视图中显示。单元依赖关系图可能仅针对包显示。）

Answer 12

度量标准可能有助于确定项目中的改进或降级，并且当然可以发现风格和约定违规，但无法替代同行代码审查。 没有它们，您就不可能知道代码的质量。

哦...这假设您的代码审查中至少有一个参与者有线索。

Answer 13

我同意你的观点，代码度量不应该替代代码审查，但我认为它们应该补充代码审查。 我认为这又回到了那句老话“你无法改进你无法衡量的东西”。 代码度量可以为开发团队提供可量化的“代码味道”或可能需要进一步调查的模式。 大多数静态分析工具中捕获的指标通常是在我们领域短暂的研究过程中确定的具有重要意义的指标。

Answer 14

指标不能替代代码审查，但它们要便宜得多。 它们是最重要的指标。

Answer 15

答案的一部分是，一些代码指标可以让您快速、初步地回答这个问题：这段代码是什么样的？

甚至“代码行”也可以让您了解您正在查看的代码库的大小。

正如另一个答案中提到的，指标的趋势为您提供了最多的信息。

Answer 16

指标本身并不是特别有趣。 重要的是你对他们做什么。

例如，如果您要测量每行代码的注释数量，您认为什么是好的值？ 谁知道？ 或者更重要的是，每个人都有自己的看法。

现在，如果您收集了足够的信息，能够将每行代码的评论数量与解决错误所花费的时间或发现的归因于编码的错误数量相关联，那么您可能会开始找到一个经验有用的数字.

在软件中使用度量标准和在任何其他过程中使用任何其他性能度量之间没有区别 - 首先测量，然后分析，然后改进过程。 如果你所做的只是测量，那你就是在浪费时间。

编辑：回应 Steven A. Lowe 的评论 - 这是绝对正确的。 在任何数据分析中，必须小心区分因果关系和单纯的相关性。 根据适用性选择指标很重要。 尝试衡量咖啡消耗量和归因于代码质量是没有意义的（尽管我确定有些人已经尝试过；-)）

但在找到关系（因果关系与否）之前，您必须拥有数据。

选择要收集的数据取决于您希望验证或改进的流程。 例如，如果你试图分析你的代码审查程序的成功（使用你自己对“成功”的定义，是减少错误或减少编码错误，或者更短的周转时间或其他什么），那么你选择衡量指标总错误率和审查代码中的错误率。

因此，在收集数据之前，您必须知道您想用它做什么。 如果指标是手段，那么目的是什么？

Answer 17

我认为指标的微小变化没有意义：复杂度为 20 的函数不一定比复杂度为 30 的函数更干净。但运行指标以寻找大的差异是值得的。

有一次我调查了几十个项目，其中一个项目的最大复杂度值约为 6,000，而其他所有项目的复杂度值都在 100 左右或更低。 这就像棒球棒一样击中了我的头。 显然，那个项目正在发生一些不寻常的事情，而且可能很糟糕。

Answer 18

我们是程序员。 我们喜欢数字。

另外，您打算做什么，而不是描述代码库的大小，因为“代码行度量无关紧要”？

举一个愚蠢的例子，150 行代码库和 1.5 亿行代码库之间肯定存在差异。 而且这不是一个很难获得的数字。