This document is licenced by Attribution 2.1 Japan (CC BY 2.1)
Published : 2013-05-03
Last updated : $Date: 2013-10-15 00:52:26 +0900 (Tue, 15 Oct 2013) $
In this page, I publish private build of Checkstyle.
I created patch to add new feature because I felt this is needed.
I send it to project page of Checkstyle.
And more, I will publish private build that applied the patch.
I am very happy if you like it and use it!!
2013-10-15 updated.
Sorry, this patch is not marged. But I'll keep this page for future use.
In the Checkstyle5.6, violation is represented by 3 leveled severity. But this is insufficient in practical use. For example, if you use FileLengthCheck (check if the java source code have lines > 2000.) , all severity level that you can use is 3 to represent 4 example case below.
They should be represented by different severity level. Only 3 level is insufficient. To represent severity in detail, I added the feature to represent violation by score. You can choose the logic to calculate score.
The source code is hosted on github. The repository is here.
https://github.com/kazurof/checkstyle-scorefeature
I added some Document of Checkstyle
Checker Score
scoring
This Checkstyle calculates score for each violation. I will show some example of setting file and score calculation.
In this case, the score is determined by its severity. MethodParamPad is 2. ModifierOrder is 5. EmptyBlock is 17. Those are default score for each severity. And more, there is 'ignore' severity. But checkstyle does not report this severity. So all severity that we can use is 3 levels. The score for 'ignore' is 0.
note: This example does not use empty element tag. (a.k.a.<property />) Because SyntaxHighlighter does not show it beautifully.
You can configure score for each severity. In this case, MethodParamPad is 100. ModifierOrder is 200. EmptyBlock is 300.
You can configure score for each check. In this case, The severity for MethodParamPad is 'info', but score is 150.
Some checks that have threshold (For example , FileLength),
Score is sum of its severity and its violation size. Assume 2100 lines for some Java source code, the score is 117.
(violation size is 100. score of severity is 17.)
The list below is the check that follows this rule.
For CyclomaticComplexity, score is sum of its severity and square of its violation size. For example, for the method that its CyclomaticComplexity is 15, score is 32. (violation size is 5. 25 is square of 5. severity score is 17. sum is 32.) I believe CyclomaticComplexity is important index of the readability of a code. And it should be evaluated more seriously in the case of a higher value.
There is some option for the logic to calculate score. In this case, FileLength uses severity score, CyclomaticComplexity uses some of severity score and violation size. refer scoring document for option.
I changed xsl file to generate result report (checkstyle-noframes-sorted.xsl) to show score. And I generated a sample result report. (see linked html)
Default score for each severity is info = 2, warning = 5, error = 17. I thogut the value should be prime number because we calculate sum of score foe each file and each total score shoulde be differ. It would be allowed info = 1. But I guess it should stick to 2 as prime number! For warning and error, we can disscuss about possibility so that more large number might be better. Anyway you can use any number as you like. It is appreciate to test every number to represent the quority of source code.
This document is licenced by
Attribution 2.1 Japan (CC BY 2.1)