cyclomatic-complexity - 早期返回语句和圈复杂度

Question

我更喜欢这种早期返回的写作风格:

public static Type classify(int a, int b, int c) {
    if (!isTriangle(a, b, c)) {
        return Type.INVALID;
    }
    if (a == b && b == c) {
        return Type.EQUILATERAL;
    }
    if (b == c || a == b || c == a) {
        return Type.ISOSCELES;
    }
    return Type.SCALENE;
}

不幸的是，每个 return语句增加了 Sonar 计算的圈复杂度指标。考虑这个替代方案:

public static Type classify(int a, int b, int c) {
    final Type result;
    if (!isTriangle(a, b, c)) {
        result = Type.INVALID;
    } else if (a == b && b == c) {
        result = Type.EQUILATERAL;
    } else if (b == c || a == b || c == a) {
        result = Type.ISOSCELES;
    } else {
        result = Type.SCALENE;
    }
    return result;
}

Sonar 报告的后一种方法的圈复杂度比第一种方法低 3。有人告诉我，这可能是 CC 指标实现错误的结果。或者 Sonar 是正确的，这真的更好吗？这些相关问题似乎不同意这一点:

https://softwareengineering.stackexchange.com/questions/118703/where-did-the-notion-of-one-return-only-come-from

https://softwareengineering.stackexchange.com/questions/18454/should-i-return-from-a-function-early-or-use-an-if-statement

如果我添加对更多三角形类型的支持， return语句加起来会对度量产生重大影响并导致 Sonar 违规。我不想贴 // NOSONAR在方法上，因为这可能会通过将来添加到方法中的新功能/错误来掩盖其他问题。所以我使用第二个版本，尽管我不是很喜欢它。有没有更好的方法来处理这种情况？

Answer 1

不是真正的答案，但评论太长了。
这个 SONAR 规则似乎被彻底打破了。你可以重写

b == c || a == b || c == a

作为

b == c | a == b | c == a

并在这个奇怪的游戏中获得两分(甚至可能会提高一些速度，因为分支很昂贵；但这取决于 JITc，无论如何)。
old rule声称，圈复杂度与测试数量有关。 new one没有，这是一件好事，因为显然您的两个片段的有意义测试的数量完全相同。

Is there a better way to handle the situation?

实际上，我确实有一个答案:对于每个提前返回使用 |而不是 ||一次。 :D
现在严肃:有一个错误请求 annotations允许禁用标记为固定的单个规则。我不再看下去了。