Cyclomatic complexity of scala [closed]

Question

Is there a tool for generating cyclomatic complexity of scala code ?

Thank You

Answer 1

To the best of my knowledge, there are no such tools. I think it's important to note that cyclomatic complexity is a fundamentally procedural metric, and it falls over completely when you have higher-order functions in your language. If you write code in "good" Scala style, the cyclomatic complexity literally goes to 1 for your entire code base. The reason is that higher-order frameworks have a tendency to avoid explicit branches altogether. Everything is encoded in terms of functions, and it's not particularly clear how to measure the cyclomatic complexity of a higher-order function (hence, everything goes to 1).

I would advise you to abandon the idea of measuring cyclomatic complexity in the context of Scala, or really any other functional language. A better, and actually more informative metric, would be to simply grep through the code for if and match/case statements. When you find them, consider making them go away. These statements aren't bad by any means, but there are many cases where they can be replaced by a straight-line, higher-order function. This examination will accomplish the same goal as a cyclomatic complexity metric, but much more usefully w.r.t. the functional paradigm. And, at the end of the day, it is likely that your code will be far more "functional" and vastly more composable as a result.

To extend Daniel's comment, the same issues actually arise any time you can encode higher order functions. That means, in particular, cyclomatic complexity doesn't apply well to OO. If a method calls b.foo then there is an invisible branch point - a branch to any of the foo methods that could possibly be reached that way. Yet most cyclomatic complexity measures for Java or whatever don't count messsage sends as branch points. It's entirely possibly (though not commonly practiced) to remove all ifs, all fors and whiles, etc via plain old OO. The only difference between OO and FP along these lines is that replacing loops and conditionals with higher level constructs is considered normal FP practice.

Answer 2

Scalastyle:

http://www.scalastyle.org/rules-0.5.0.html

Odersky considers cyclomatic complexity important in FP, and this is a Scala question.