For existing systems Sonargraph might produce a huge number of issues. This is expected, if no static code analysis has been used before, so don't be discouraged! Now, what issues should be fixed first? We have implemented an algorithm in Sonargraph that borrows the main idea from "The Eisenhower Method"[5], that a problem has importance and urgency dimensions. The algorithm computes numbers for both and treats them as coordinates. The resulting score is defined as the distance from origin.
The goal of this algorithm is identifying those issues were fixes provide the most benefit. There is not much benefit in fixing issues in code that has not been changed during the last year. On the other hand, recently introduced issues are usually easier to fix since the context is still present in the developer's head. Also, issues that have a great impact like huge cycle groups that involve frequently changed code and that could be resolved by eliminating a small number of dependencies provide a higher benefit than refactoring a slightly too complex method.
The importance of an issue is computed including the issue category (e.g. architecture violation, threshold violation), severity and impact (e.g. the lines of code involved in a cycle group, the number of involved lines in a duplicate code block) as parameters.
The urgency is computed by including data from the source control management (SCM) to generate a boost for issues involving files that have been changed frequently and from the System Diff (see Chapter 14, Examining Changes) to generate a boost for new or worsened issues. Additionally, the number of references to break up a cycle group is included in the urgency calculation to generate a boost for cycle groups that are now still easy to fix, also known as 'low-hanging fruit'. Similarly, the 'tolerance' (lines being different) in duplicate code blocks is included to generate a boost for duplicate code blocks where it is now still easy to extract common logic, i.e. duplicate code blocks with a low tolerance.
NOTE
Treat the computed scores and the ranking as hints! Let us know if you notice that a certain type of issue is constantly ranked either too high or too low, or if you require further configuration options.
Details of the algorithm and individual computed values are displayed in the Properties view for a selected issue (see screenshot below). Large cycle groups usually get a very high score, since their impact on the system is high and it is likely that any of the involved sources have been modified. The selected duplicate code block shows a high "Urgency Ease of Fix" as both occurrences are identical (0 reported tolerance) and is therefore a low-hanging fruit.
