您维护的任何功能中最高的环复杂性是什么？您将如何进行重构？ [英] What is the highest Cyclomatic Complexity of any function you maintain? And how would you go about refactoring it?

问题描述

我正在使用 NDepend 对我维护的旧系统进行一些探索（出色的工具可以将其检出）， 另一天。我的发现几乎使我在屏幕上洒了满口咖啡。

I was doing a little exploring of a legacy system I maintain, with NDepend (great tool check it out), the other day. My findings almost made me spray a mouthful of coffee all over my screen. The top 3 functions in this system ranked by descending cyclomatic complexity are:

1. SomeAspNetGridControl.CreateChildControls（CC为171 ！！）
>

2. SomeFormControl.AddForm（CC为94）


3. SomeSearchControl.SplitCriteria（CC为85）

1. SomeAspNetGridControl.CreateChildControls (CC of 171!!!)
2. SomeFormControl.AddForm (CC of 94)
3. SomeSearchControl.SplitCriteria (CC of 85)

我的意思是171，哇！！！ 低于20 还是不应该？所以这让我感到奇怪。您维护或重构的最复杂的功能是什么？以及如何重构这种方法？

I mean 171, wow!!! Shouldn't it be below 20 or something? So this made me wonder. What is the most complex function you maintain or have refactored? And how would you go about refactoring such a method?

注意：我测量的CC是通过代码而不是IL进行的。

Note: The CC I measured is over the code, not the IL.

推荐答案

与几年前我工作的1970年代老式COBOL相比，这是孩子们的东西。我们使用原始的 McCabe 工具以图形方式显示某些代码的CC。打印输出是纯黑色的，因为显示功能路径的线条非常密集且像意大利面条。我没有数字，但它必须比171高得多。

This is kid stuff compared to some 1970s vintage COBOL I worked on some years ago. We used the original McCabe tool to graphically display the CC for some of the code. The print out was pure black because the lines showing the functional paths were so densely packed and spaghetti-like. I don't have a figure but it had to be way higher than 171.

每个代码完成（第一版）：

如果分数是：

• 0-5-例程可能很好


• 6-10 -开始考虑简化例程的方法


• 10+-将例程的一部分分解为第二个例程，并从第一个例程中调用它

在破坏原始例程时编写单元测试可能是一个好主意。

Might be a good idea to write unit tests as you break up the original routine.

这篇关于您维护的任何功能中最高的环复杂性是什么？您将如何进行重构？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！