Im trying to analyse the cyclomatic complexity of a codebase using the MetricsReloaded plugin in Android Studio (should be the same as IntelliJ).
I have it working and get the output but am unsure on what the output actually means. The output I see is:
Can anyone tell me what this means and what defines whether that is "good"/"bad"?
Thanks for any help :)
The metrics in your screen shots are showing the cycolomatic complexity (CC) of your code at different levels of granularity. The first screen shot (with the first tab titled Method metrics) is the most granular, showing the cyclomatic complexity for each method in the project. The second screen shot is doing the same thing at the class level, and so on up to the rightmost tab which shows the metrics for the entire project.
The averages and totals on the rightmost four tabs all flow up from the values on the Method metrics tab, so focus on that.
As a starting point, the numbers of greatest interest are those under the v(G) column in your first screenshot, showing the CC for each method as an integer value. The PMD documentation offers the following guidelines for determining whether those numbers are "good"/"bad":
Complexity is determined by the number of decision points in a method plus one for the method entry. The decision points are 'if', 'while', 'for', and 'case labels'. Generally, 1-4 is low complexity, 5-7 indicates moderate complexity, 8-10 is high complexity, and 11+ is very high complexity.
Methods with high CC values loosely correspond to methods that we would find complex at first glance, and vice versa. For example, bean getters/setters should have a v(G) of 1 since they don't do much.
The numbers on your first screen shot are all below 6 so there is not much to worry about. However, if a method had a high value for v(G) you would then want to look at the two values to its left, ev(G) and iv(G). For example, if you had a method with an iv(G) value of 1 and an ev(G) value of 15 then the method would not be making any calls to other methods, but would have some complex internal logic (perhaps nested loops) that might be worth refactoring.
There's obviously far more it than that, but keeping an eye on the v(G) column on the Method metrics tab is probably the single most important thing to do.
