循环复杂性可以帮助我们避免编写复杂的代码，因为这些代码更容易出错，测试起来更加复杂，并且难以推理。 我会特别注意后者，因为这意味着可读性低和维护成本高。 例如，if / else语句通常用于：
if THIS then
do some logic in order to return THAT
if THAT then
do some logic in order to return THIS
if SOMETHINGELSE then
do some logic in order to return THAT and THIS
else
do some logic in order to return THIS and THAT
通常，每个块都包含一些逻辑以便执行某些操作。 自然，每条逻辑都需要引起注意，因为必须理解一个块在做什么，它的目的是什么以及预期结果是否正在产生。 现在，想象一个具有20条条件语句的函数，其中每个条件语句产生一个不同的结果，您必须解释（并记住）该函数返回的所有值是什么，以及在什么条件下返回。 可能您已经明白了。
但是，请注意，循环复杂度不会尝试确定控制流程图中每个路径的复杂程度。 它并没有尝试了解程序体系结构的每个模块，而是着重于大多数程序的编写方式，并假设所有情况都相同。 为了提供帮助，它假定所有执行路径都包含特定且唯一的逻辑，就像大多数时候一样。 自从我开始使用Go 编程以来，我一直在思考这一点。 按照我们在Golang中使用的错误处理模式，请检查另一个示例：
THIS, ERR := fnGetThis()
if ERR then
return error
THAT, ERR := fnGetThat()
if ERR then
return error
SOMETHINGELSE, ERR := fnGetSomethingElse()
if ERR then
return error
WHATEVER, ERR := fnGetWhatever()
if ERR then
return error
do some logic in order to produce the expected result using THIS, THAT, SOMETHINGELSE and WHATEVER
在我看来，所有仅返回错误且没有额外逻辑的if语句都不会出错，也难以推理，也很难解释整个块的目的。 一旦它需要的一切都起作用，它就会做一件事。
如果我们可以选择放弃仅返回错误而没有其他事情的情况，也许可以提供更好的圈复杂度分析。 由于产生这些错误的真正复杂性不是写在这里，而是写在要调用的函数中。
我想听到更多关于这个问题的想法，因为我的目的是讨论这个问题。 因此，随时发表评论????。
From: https://hackernoon.com/thoughts-on-cyclomatic-complexity-in-golangs-world-51db3507e1ec