寻求关于构造代码的说明以减少圈复杂度

最近,我们公司已开始每周测量代码中的功能的圈复杂度(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中反映出来了吗？

是.你的第一个例子有一个决定点而你的第二个例子没有,所以第一个例子有一个更高的CC.

是的 - 也许,你的第一个例子有多个决策点,因此有更高的CC.(见下面的解释.)

也许吧.显然他们有相同数量的决策点,但有不同的方法来计算CC,这意味着......

...如果您的公司以特定方式测量CC,那么您需要熟悉该方法(希望他们使用工具来执行此操作).有不同的方法来计算不同情况下的CC(案例陈述,布尔运算符等),但无论您使用什么约定,都应该从度量中获得相同类型的信息.

更大的问题是其他人提到的,你的公司似乎更关注CC而不是其背后的代码.一般来说,确定,低于5是好的,低于10是好的,低于20是好的,21到50应该是一个警告标志,高于50应该是一个大警告标志,但那些是指南,而不是绝对的规则.您应该检查CC高于50的过程中的代码,以确保它不仅仅是一大堆代码,但可能有一个特定的原因,为什么程序是这样编写的,并且它是不可行的(对于任何重构的原因)

如果您使用工具重构代码以减少CC,请确保您了解工具正在做什么,并且他们不是简单地将一个问题转移到另一个地方.最终,您希望您的代码缺少一些,正常工作,并且相对容易维护.如果该代码也具有低CC,那么它就是好的.如果您的代码符合这些标准并且CC高于10,那么可能是时候坐下来管理您的代码并保护您的代码(也许让他们检查他们的政策).

浏览维基百科条目和Thomas J. McCabe的 原始论文后,您上面提到的项目似乎是已知的度量问题.

但是,大多数指标确实有利有弊.我想在一个足够大的程序中,CC值可能指向代码中可能复杂的部分.但是,更高的CC并不一定意味着复杂.

像所有软件指标一样，CC也不完美。在足够大的代码库上使用，它可以使您了解可能存在问题的区域。

这里有两件事要记住：

足够大的代码库：在任何不重要的项目中，您都将拥有具有很高CC值的函数。如此之高，以至于在您的一个示例中CC是否为2或3都不重要。CC等于300的函数肯定是需要分析的东西。抄送是301还是302都没关系。

别忘了用你的头。有些方法需要很多决策点。通常，可以将它们重构为更少的数量，但有时却不能。不要遵循“使用CC> xy重构所有方法”之类的规则。看看它们，然后用你的大脑来决定该怎么做。

我喜欢每周分析的想法。在质量控制中，趋势分析是在问题创建过程中识别问题的非常有效的工具。这比等待它们变大以致变得明显起来要好得多（有关详细信息，请参阅SPC）。