回答

1

圆形复杂性不依赖于语言/技术。它是从函数中的逻辑可能路径计算出来的。

没有'最大'圈复杂度。 它越高代码越难以快速理解。 它越高,错误地理解它的机会就越高,并且如果您必须对其进行修改,则会在该函数中引入错误。

如果要维护您的代码,或者您的代码要发展,则必须考虑这一点。 (维护费用远远低估。)

这个SO问题Do you find cyclomatic complexity a useful measure?有一些有价值的答案。

我个人使用的规则是7.(科学研究表明人类大脑一次只能掌握7个事物/概念)。当CC> = 7,当函数的行数> = 7,当我的类有> = 7个数据成员,当我的函数有> = 7个参数时,我开始质疑我的设计...等等。

+0

CC> 7通常是一个问题,OP的“25”将是疯狂的。该规则有例外,但有些仅适用于某些语言。如果语言强迫你使用else-if链而不是表查找,你有相同的复杂性,但正式增加你的CC。另外我想知道如何编写一个角度控制器,处理少于7行的超过5个输入的形式。 – Giszmo 2015-03-13 05:05:26

1

我想,没有确切的答案。 25的CC很可能无法在任何语言中维护,并且是从一种语言到另一种语言存在差异。在某些语言中,您可以将函数引入到字典中,并从该字典中选择函数将CC增加1,而在没有lambda的其他语言中,您将使用开关或甚至一个else-if链会为每个案例添加一个CC,但如果所有案例均以return;为例,则可维护性不会成为问题。

正如Stephane所说,7是一个很好的数字,并且存在静态代码分析工具,它们默认为Java的7,但您总是会遇到异常情况,将函数分成两部分会正式减少CC,但人类会有一个更难以跟上发生的事情。考虑到它,角控制器通常会有一个非常低的CC(< = 2),因为它们只定义了函数和变量。虽然这些函数在CC的意义上可能看起来是“复杂的”,但promises没有向CC添加任何内容,因为现在的代码流将位于另一个函数中(例如,success()failure()failure())。

相关问题