Simple question. SonarQube has a duplicate code scanner. Does it examine comment blocks in this algorithm? If I have 1000 source files with the same copyright header, will it detect these as duplicated code?
From the SonarQube documentation on duplications:
SonarQube allows to detect "Type 2" duplications which means : structurally/syntactically identical fragments except for variations in literals and comments.
So your copyright header will not be counted as duplication.
Related
Is there a fast way to see how many lines of code are in my Stata do-file (.do), not counting the comments? I could make a new version and delete all the comments out by hand, but that's too tedious for what I need.
My intent is to compare the lengths of an old version vs. a new version of the do file. I want to see whether I have made the code more efficient. However, I have some large commented sections of non-vital code in the files that I don't need to count.
A closely related question: is there a way to quickly see a total of all lines of code in a project (rather than just the do-file) - either including or excluding comments? Thank you.
I am trying to figure out whether sonar can identify commented out tags . These tags contain some valid code lines which should not be marked as a violation. Currently, the whole highlighted part is marked as a major violation. We need to skip this violation. I know people will suggest to mark it is a false positive but we can't keep on marking every violation of this type. Is there a permanent solution available? This type of commenting is valid as per Microsoft standards : http://msdn.microsoft.com/en-us/library/9w4cf933
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.
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.
What information do you consider worth to put in the comment at the beginning of a sourcecode file?
All I could think about was the name of the author and perhaps the date the file was created (although I'm not to sure if there is any useful value to this information).
[EDIT] To clarify, I don't mean comments before a class, but at the first lines of the file, before include statements and what else. Like
/**
* Author: Name
* Created: 11.05.2009
*
* (c) Copyright by Blub Corp.
**/
What to put in the file header:
Library/component that source code is part of
Copyright details
Brief and meaningful description of class(es) in source file
What NOT to put in the file header:
Anything that duplicates low level logic which is part of the code itself. This can lead to maintenance problems if it isn't updated when the source code changes.
Author name(s). Why?
In the world of revision control systems, while there may be an initial author of some code, eventually ownership becomes blurred. This is especially true when code enters the maintenance phase of the life cycle where owners can change regularly.
All code eventually becomes "community wiki" after enough changes ;-)
Would you want your name associated with all of the code forever, knowing full well that you will not be responsible for the code until its death?
Creation and last changed dates. This is for similar reasons as list above. Revision control includes this information - why duplicate it in the header, making more work for yourself and risking leaving inaccurate information in the comment when things inevitably change?
Copyright
Original author(s)
License (if it's open-source)
One-line purpose statement or description
Further overall documentation and usage examples
Edit: Changed Author(s) to Original Author(s)
if the file is going to contain some very common class / functionality which can be understood with reasonable common sense, then you dont really need to put much in the description otherwise if the source code file is a class / function very specific to the project or is encompassing a complicated logic, then you should give a high level overview & purpose of the source code file.
File Encoding! (utf-8)
# -*- encoding: utf-8 -*-
Especially if you plan on sharing your code with someone else in some other part of the world at some point.
with all the above also put sort detail of the purpose of the code in that file also something u think can be helpful in debugging and understanding the functionality.this help in maintainence and support.