圈复杂度的常见原因及其解决方案答案

【问题标题】：Common causes of Cyclomatic Complexity and their solutions圈复杂度的常见原因及其解决方案
【发布时间】：2010-02-02 16:27:30
【问题描述】：

在工作中，我们正在研究导致高圈复杂度的常见问题。例如，具有较大的 if-else 语句会导致高圈复杂度，但可以通过用多态替换条件来解决。你还发现了哪些其他例子？

【问题讨论】：

任何具有分支行为的结构都会增加圈复杂度
en.wikipedia.org/wiki/Cyclomatic_complexity:
你说“圈复杂度”就像它本质上是一件坏事。通过查看导致实际问题的原因，您不会做得更好吗？
是的，我们知道 cc 是什么 - 一个好的做法是确保 cc 不高，否则在尝试调试该区域的错误时会增加引入新错误的风险，因为它过于复杂.有一些常见的不良做法会导致这些不良的高水平 cc - 比如 big if else 语句，我想知道其他人是否遇到过其他导致低水平的不良做法。

【解决方案1】：

请参阅 NDepend 的 definition of Cyclomatic Complexity。

Nesting Depth 也是一个很好的代码指标。

圈复杂度是一种流行的程序软件度量，等于程序中可以做出的决定的数量。具体来说，在 C# 中，方法的 CC 是 1 + {在方法主体中找到的以下表达式的数量}：

如果 |而|为|前锋 |案例 |默认 |继续 |转到 | && | || |抓住|三元运算符 ?: | ??

以下表达式不计入 CC 计算：

其他 |做 |开关 |试试 |使用 |扔|最后 |返回 |对象创建 |方法调用 |字段访问

适应 OO 世界，该度量标准在方法和类/结构上定义（作为其方法 CC 的总和）。注意匿名方法的CC在计算其外部方法的CC时不计算在内。

建议：CC 高于 15 的方法难以理解和维护。 CC 高于 30 的方法非常复杂，应该拆分成更小的方法（除非它们是由工具自动生成的）。

【讨论】：

【解决方案2】：

另一个避免使用这么多 if 的例子是有限状态机的实现。因为事件触发转换，所以条件以更清晰的方式隐含，这些转换改变了系统的状态。控制更简单。

给你一个链接，其中提到它的一些好处：

【讨论】：