How to analyze jQana report
jQana reports the metrics: CC (Cyclomatic Complexity), LCOM4, and RFC, grouping by PROJECT, PACKAGE and CLASS. You can drill down CC metrics until the method level.
The aggregation function used for each metric may vary. For CC is average, for LCOM4 is the highest value found for each class, and for RFC is the average.
jQana is a very bad tempered tool, and have fixed tolerance limits:
- CC: 5 for each method;
- LCOM4: 1 for each class;
- RFC: 50 for each class;
No, you can't change this! The only way to change is to download the source code and create your own version.
If any element violates a metric limit, then, the class, package and project is marked, with the value in bold red font.
What does it mean?
Well, first of all, let's discuss CC. High CC value means that some methods in one (or more classes) are too complex, and, maybe, you need to refactor them, in order to turn the code more maintainable and testable.
There are some factors that affect negatively the CC:
- The method have low cohesion, and maybe is assuming more than one responsability;
- The method have too much loops and if nests, it is better to refactor it;
Whenever is possible, you should promote reuse in your projects. Maybe you are "reinvent the wheel", and you should look for a third-party component that provides you what you need.
Then, we have LCOM4, which means: Lack of Cohesion of Methods. The "4" means that it is Hitz's and Montazeri's revision. It measures how many "connected components" exist in one class. There must be only one! If you have more than one connected component, then the class (maybe) violates the SRP - Single Responsability Principle, It is a low cohesion class!
Low cohesion classes are very problematic! They propagate changes and are difficult to maintain and test.
But what does it mean "Connected Components"? Well, when we group methods and class' fields, we can create a graph, where the vertices are methods or class fields, and the edges represent utilization. If we have all the fields and methods connected, we have just one component. If we have more than one component, then we may have a low cohesion class.
Sometimes, low cohesion classes are a good solution, for example: Context classes, Utility classes, as long as you know what you are doing, it is ok. But, as a general rule, you should avoid such classes, refactoring them in separate classes.
Finally, we have RFC - Response for Class, which is a measure of coupling, but it also measures complexity and cohesion. High complex low cohesion classes tend to have a high value of RFC, meaning that they are hard to maintain and test.
If you have a class with RFC greater than 50, you must refactor it. But this does not mean that a class with RFC 50 (or near) is in a good shape. Generally, you should be aware of all classes with RFC between 25 and 50 (the top half).
Main causes of high RFC:
- Utility classes;
- Bad modelling - Classes representing more than none entity;
- Violations of SRP - Single Responsability Principle;
- Classes generated by frameworks;
I these cases, whenever is possible (generated classes is not the case), you should refactor the offending class.