We're just switching our metrics gathering to sonar. We previously used sloccount to get the lines of code and are now using sonar but the counts are coming up as around 40% different. Does anyone know what the differences are and if there is any configuration that I should do in sonar to align the two?
On sonar side this is pretty simple : each line containing a character which is neither a blank character or a character part of a comment is considered to be part of a line of code and there is no way to tune this behavior.
Related
I noticed one bug in SonarQube.
In Rule: 'Sections of Code should not be "commented out"'
When I add a trailing comma at the end the the sonar is not detecting this and giving no error. Is anything I can do here?
Implementations of this rule use heuristics. Apparently when you added the comma, it tipped over in the heuristic's eyes from being code to non-code text.
To make sure the commented-out code is picked up again, make it less text-y. I.e. remove the non-code characters such as ','.
I have been unsuccessful in discovering how to force the "output window" in Zerobrane to show the entire output. My setup is inserting a CR at about column 80 followed by a few characters and ... on the next line. My dozen searches for various key words has not produced a solution. Any solutions to this issue? I'd think some configuration option might set this up but ????.
I don't see any truncation in v1.30 or v1.40 of ZeroBrane Studio (I've tried with lines of up to 10,000 characters in length). You may want to upgrade if you are using some of the older versions.
I was wondering if there is a way to trick sonar into neglecting commented out code while still keeping it inside. I would like to leave the snippet of code in there for modifications at a later date but would also like to increase compliance.
I have this for example
// bdgItems.setGpIncrease(zero); and this is where i get compliance issuses. on the other hand regular comments like // get data points is no cause for issue. I'd like to keep the commented code in there to pick up where I left off in the next cycle of development, but like i said, reduce the issues. Ive tried a few ways in tricking it like // [DELETE THIS] bdgItems.setGpIncrease(zero); or // bdgItems . setGpIncrease ( zero ); with spaces in between words but it still knows! I was wondering if some of you vets knew any tricks [i'm fairly new to sonar].
Thanks in advance!
It's not recommended, as Mithfindel already advised.
Simply replace dots and semi-colons with underscore.
Code sample: documentClient.deleteDatabase("dbs/" + DATABASE_ID, null);
The resulting comment without the warning would be: // documentClient_deleteDatabase("dbs/" + DATABASE_ID, null)_
This is a typical technical debt management issue.
If you "leave it there for later", then you are indeed adding technical debt into your source code, that you intend on repaying later. So SonarQube flagging this commented out code as issues is intended behavior.
You still have the option to flag those issues as false positives, but I do believe you should keep them as true issues, if only to remind yourself of coming back to fix them.
Checkstyle Magic Number settings in SonarQube 4.4
In the documentation above, it says that having a comma separated list eg: "1,2,3,4,5" for ignoreNumbers will work. However, when I try to list out the numbers in a comma separated fashion, it fails. The only way I have gotten it to work is setting ignoreNumbers as a single integer.
This is a known bug that affects the Checkstyle plugin with SonarQube 4.4+ versions.
Feel free to watch and vote for it: SONARCHKST-5
Some lines of codes don't need to be checked by Sonar (Sonarqube.org). How can I just disable checking on these lines? Is there any way like just addding annotation "#" to make these lines invisible for Sonar? Thank you!
There are several ways. See FrequentlyAskedQuestions-NOSONAR and further down that page to see both a comment (//NOSONAR) and annotation (#SuppressWarnings) options, as well as some other ways to disable checking.
From official docs:
How do I get rid of issues that are False-Positives?
False-Positive and Won't Fix You can mark individual issues False Positive or Won't Fix through the issues interface. If you're using
Short-lived branch and PR analysis provided by the Developer Edition,
issues marked False Positive or Won't Fix will retain that status
after merge. This is the preferred approach.
//NOSONAR Most language analyzers support the use of the generic mechanism: //NOSONAR at the end of the line of the issue. This will
suppress the all issues - now and in the future - that might be raised
on the line.