Cyclomatic complexity of scala [closed]

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.

---

Questions asking us to recommend or find a book, tool, software library, tutorial or other off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and s开发者_如何学JAVApam. Instead, describe the problem and what has been done so far to solve it.

Closed 8 years ago.

Improve this question

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

Thank You

---

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.

---

Scalastyle:

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

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

---

You can run a task in the SBT tool to check for common style problems. Among other things, it will raise a warning if cyclomatic complexity goes over 10 in any block. For more details, check here: http://www.scala-sbt.org/

The task is called styleCheck.