寻求有关构建代码以降低圈复杂度的澄清

Question

最近，我们公司开始每周测量代码中函数的圈复杂度（CC），并报告哪些函数得到了改善或恶化。 所以我们开始更加关注函数的 CC。

我读过，CC 可以非正式地计算为 1 + 函数中决策点的数量（例如 if 语句、for 循环、select 等），或者也可以是通过函数的路径数...

我知道最简单的减少CC的方法是反复使用Extract Method重构...

有些事情我不确定，例如以下代码片段的CC是什么？

1）

for (int i = 0; i < 3; i++)
    Console.WriteLine("Hello");

它们

Console.WriteLine("Hello");
Console.WriteLine("Hello");
Console.WriteLine("Hello");

都做同样的事情，但是第一个版本是否因为 for 语句而具有更高的 CC？

2)

if (condition1)
    if (condition2)
        if (condition 3)
            Console.WriteLine("wibble");

假设

if (condition1 && condition2 && condition3)
    Console.WriteLine("wibble");

该语言进行短路求值，例如 C#，那么这两个代码片段具有相同的效果...但是第一个片段的 CC 是否更高，因为它有 3 个决策点/if 语句？

3）

if (condition1)
{
    Console.WriteLine("one");

    if (condition2)
        Console.WriteLine("one and two");
}

这

if (condition3)
    Console.WriteLine("fizz");

if (condition4)
    Console.WriteLine("buzz");

两个代码片段做不同的事情，但是它们有相同的CC吗？ 或者第一个片段中的嵌套 if 语句是否具有更高的 CC？ 即嵌套的 if 语句在心理上更难以理解，但这是否反映在 CC 中？

Answer 1

1. 是的。 您的第一个示例有一个决策点，而第二个示例没有，因此第一个示例具有更高的 CC。
2. 是的，也许，你的第一个例子有多个决策点，因此有更高的 CC。 （参见下文的解释。）
3. 是的——也许吧。 显然他们有相同数量的决策点，但是计算CC的方法不同，这意味着……

如果你的公司正在以特定的方式测量CC，那么你需要熟悉该方法（希望他们正在使用工具来执行此操作）。 对于不同的情况（case 语句、布尔运算符等）有不同的计算 CC 的方法，但无论使用哪种约定，您都应该从度量中获得相同类型的信息。

更大的问题是其他人提到的，你们的公司似乎更关注 CC，而不是其背后的代码。 一般来说，当然，低于 5 很好，低于 10 很好，低于 20 还可以，21 到 50 应该是一个警告信号，高于 50 应该是一个很大的警告信号，但这些只是指导，而不是绝对规则。 您可能应该检查 CC 高于 50 的过程中的代码，以确保它不仅仅是一大堆代码，但也许有一个特定的原因导致该过程以这种方式编写，并且它是不可行的（对于任何多个原因）来重构它。

如果您使用工具重构代码以减少 CC，请确保您了解这些工具的作用，并且它们不仅仅是将一个问题转移到另一个地方。 最终，您希望您的代码几乎没有缺陷、能够正常工作并且相对易于维护。 如果该代码的 CC 也较低，那就太好了。 如果您的代码符合这些标准并且 CC 高于 10，那么也许是时候与您能找到的任何管理层坐下来捍卫您的代码（或许还可以让他们检查他们的政策）。

Answer 2

浏览维基百科条目和 Thomas J. McCabe 的原始论文后，似乎这些项目您上面提到的是该指标的已知问题。

然而，大多数指标确实都有优点和缺点。 我想在一个足够大的程序中，CC 值可能指向代码中可能复杂的部分。 但更高的 CC 并不一定意味着复杂。

Answer 3

与所有软件指标一样，CC 并不完美。 在足够大的代码库上使用时，它可以让您了解哪里可能是有问题的区域。

这里需要记住两件事：

1. 足够大的代码库：在任何重要的项目中，您都会拥有具有非常高的 CC 值的函数。 如此之高，以至于在您的一个示例中，CC 为 2 或 3 并不重要。假设 CC 超过 300 的函数绝对值得分析。 CC 是 301 还是 302 都没关系。
2. 别忘了用你的头脑。 有些方法需要许多决策点。 通常可以通过某种方式重构它们以减少数量，但有时却不能。 不要遵循“用 CC > xy 重构所有方法”之类的规则。 看看它们并用你的大脑来决定做什么。

我喜欢每周分析的想法。 在质量控制中，趋势分析是在问题产生期间识别问题的非常有效的工具。 这比必须等到它们变得太大而变得明显要好得多（请参阅SPC了解一些细节）。

Answer 4

CC 并不是衡量质量的灵丹妙药。 显然，重复语句并不比循环“更好”，即使循环具有更大的 CC。 循环具有较大 CC 的原因是有时它可能会被执行，有时可能不会，这会导致两种不同的“情况”，都应该进行测试。 在你的例子中，循环将总是执行三次，因为你使用了一个常量，但 CC 不够聪明，无法检测到这一点。

与示例 2 中的链式 if 相同 - 此结构允许您拥有一个只有条件 1 和条件 2 为 true 时才会执行的语句。 这是一种特殊情况，在使用 && 的情况下是不可能的。 因此，即使您不在代码中使用 if 链，它在特殊情况下也具有更大的潜力。

Answer 5

这就是盲目应用任何指标的危险。 CC 指标当然有很多优点，但与任何其他改进代码的技术一样，它不能脱离上下文进行评估。 向您的管理层指出 Casper Jone 对代码行测量的讨论（希望我能为您找到一个链接）。 他指出，如果代码行数是衡量生产力的一个很好的衡量标准，那么汇编语言开发人员就是地球上生产力最高的开发人员。 当然，他们并不比其他开发人员更有效率； 他们只是需要更多的代码来完成高级语言用更少的源代码所做的事情。 正如我所说，我提到这一点，是为了让你的经理们知道，在没有对指标所告诉你的内容进行智能审查的情况下盲目应用指标是多么愚蠢。

我建议，如果不是，您的管理层应该明智地使用 CC 措施来发现代码中应进一步审查的潜在热点。 盲目地追求降低 CC 的目标而不参考代码可维护性或其他良好编码措施是愚蠢的。

Answer 6

圈复杂度类似于温度。 它们都是测量值，在大多数情况下如果没有上下文就毫无意义。 如果我说外面的温度是 72 度，那意义不大； 但如果我加上我在北极的事实，那么数字 72 就变得很重要了。 如果有人告诉我某个方法的圈复杂度为 10，那么在没有上下文的情况下我无法确定该方法是好是坏。

当我对现有应用程序进行代码审查时，我发现圈复杂度是一个有用的“起点”指标。 我检查的第一件事是带有 CC > 的方法 10. 这些“>10”的方法并不一定是坏的。 它们只是为我提供了审查代码的起点。

考虑 CC 编号时的一般规则：

• CC # 和测试数量之间的关系应为 CC# <= #tests
• 仅当 CC# 增加时才重构
  可维护性
• CC 高于 10 通常表示一种或多种代码气味

Answer 7

[题外话]如果您更看重指标的可读性而不是良好的分数（J.Spolsky 是否说过，“测量了什么，就完成了”？ - 我认为这意味着指标被滥用的情况比没有），通常最好使用名称良好的布尔值来替换复杂的条件语句。

然后

if (condition1 && condition2 && condition3)
    Console.WriteLine("wibble");

变成

bool/boolean theWeatherIsFine =  condition1 && condition2 && condition3;

if (theWeatherIsFine)
    Console.WriteLine("wibble");

Answer 8

我不是这个主题的专家，但我想我会给出我的两分钱。 也许这就是这一切的价值。

环复杂度似乎只是一种特定的自动快捷方式，用于查找潜在（但不是绝对）有问题的代码片段。 但真正要解决的问题不就是测试吗？ 代码需要多少个测试用例？ 如果CC较高，但测试用例数量相同并且代码更干净，则不必担心CC。

1.) 那里没有决策点。 那里的程序只有一条路径，两个版本中的任何一个都只有一个可能的结果。 第一个更简洁、更好，圈复杂度该死。

2.)两种情况各有 1 个测试用例

。) 在这两种情况下，您要么写“wibble”，要么不写。

两个测试用例

3.) 第一个可能不会产生任何结果，“一”，或“一”和“一和二”。 3条路径。 第二个可能不会导致任何结果，无论是两者中的任何一个，还是两者。 4条路径。

第一个测试用例 3 个
第二个4个测试用例