| Re: [gmf-dev] GMF Tooling is now analyzed by Sonar |
|
On 12/07/2012 10:33 PM, Michael Golubev
wrote:
I will take a look at the "critical" violations, also from the first glimpse, the word "critical" is a bit of exaggeration and there is at least some justification for at least some of the violations listed as criticals at sonar dashboard.Yes, some critical issues are not really critical. But it's good to know where code can be improved. All generated code (metamodels APIs) can be ignored. I hope one day, the EMF generators will be improved to follow clean rules. But some of them can be fixed by a small improvement, that can fix a bug or improved readability of code or performance: * empty if should be either removed or commented. They are often places where the "the" block is commented and is there for readability, whereas it's generally better to comment condition as well. The only cases where this is necessary is probably when this first emply if is there to prevent from going into an "else". * empty while are not very good for readability, they should be turned into "do { var = ... } while (var != null);" * empty finally can either be removed, or it highlights that we probably forgot to put content into the block * equals/hashCode is an issue that can introduce a big performance loss: http://eclipsesource.com/blogs/2012/09/04/the-3-things-you-should-know-about-hashcode/ * The "Useless operation on immutable" https://dev.eclipse.org/sonar/drilldown/violations/org.eclipse.gmf-tooling:parent?rule=pmd%3AUselessOperationOnImmutable&rule_sev=CRITICAL# looks like a bug. So the question is, do you know some way to suppress some of the specific violations (after careful checking -- similar to @SuppressWarnings), or change the set of the active rules or their severities? Not that I am eager to disable a lot, it is more theoretical question.I think there is a way do to this using Sonar "profiles", however I never used this so far. The @SuppressWarnings would work, but it's not recommanded to put reports configuration into code. In our case, we should investigate on a way to exclude generated code from analysis. Cheers, |