Measure the density of violations by dividing the number of violations by the size of the code base

[fniessink]

For example, 100 violations / 100.000 LOC = 1 violation / KLOC.

Limit this to SonarQube as source. The tool "Cloc" is out of scope.

Add a density scale to the violations metric: "Density ({metric.entities} per 1000 lines of code)"

Copy the "lines to count" parameter from Size metric to the violations metric so the user can use the same line count for both the size and the violation density.

Tasks:

• Update meta model by adding a density scale
• Update data model
• Update collector to deal with the new parameter
• Update changelog
• Add a note to the documentation to warn the user that violations can happen in comments too (most notably commented-out code). If the user picks "lines with code" for the "lines to count" parameter this means the numerator of the metric may contain violations present in comments while the de monitor only counts lines without comments.

[wkoot]

Implementing this as refined does not seem to be compatible with the current concept of measurements.
We run into the problem that the metric measurement "violation density" is not actually the same as "violations".
Currently there is also no proper way to add a descriptive label such as "Violation per kLOC" to the graph area.

Conceptually, we want to know something about violations only (not LOC). Just in a relative sense instead of absolute.
It might be a solution to implement a unit switch, in a similar manner as switching between scales.
Alternatively, the best way to implement this at the moment would be as a new "violation density" metric.
Or... reconsider implementing the compound metrics :-)

[fniessink]

Implementing this as refined does not seem to be compatible with the current concept of measurements. We run into the problem that the metric measurement "violation density" is not actually the same as "violations". Currently there is also no proper way to add a descriptive label such as "Violation per kLOC" to the graph area.

Conceptually, we want to know something about violations only (not LOC). Just in a relative sense instead of absolute. It might be a solution to implement a unit switch, in a similar manner as switching between scales. Alternatively, the best way to implement this at the moment would be as a new "violation density" metric. Or... reconsider implementing the compound metrics :-)

Adding a "density" scale should address these concerns.