| Re: [platform-releng-dev] Progress with Platform Build and Sonar |
|
On 07/11/2013 05:21 PM, Stephan
Herrmann wrote:
Thanks Mickael,This highly depends on the definition of false-positive. A false-positive is not something you don't care, it's something that says something wrong. It's not because you don't want to see the warning that it is not an issue. Here is the list of CRITICAL issues for JDT/Core: https://dev.eclipse.org/sonar/drilldown/violations/eclipse.jdt.core:eclipse.jdt.core?severity=CRITICAL I see some things that are not false-positive, such as: * Empty ifs that can consume CPU useless operations "if (blah) { /* comment */ }" should be more something like " /* if (blah) { comment } */ * 9 equals without hashCode, which means that the object won't work in an HashMap or HashSet Some other issues marked as critical could indeed have there severity reduced, but are still overall Java bad practices: * Code style "while (blah) { /*nothing*/ }" instead of a "do { something } while (still relevant)" * Arrays stored directly ... The goal here is not to hunt the false positive, but rather to track the real issue. Also, as the platform build consists in many projects which have different concerns, I don't think it's possible to find a set of rules that match all use cases (it's not the same way to develop SWT compared to developing PDE UI...) So, to make this analysis useful we need tuning.The goal is not to get it to 0 warnings. Instead of tuning the tool, I think it's more efficient to read its report and decide which one of those reports deserve efforts. Qualitative analysis over quantitative. - since I don't even know which tool (PMD? Checkstyle?) is givingSo far it's using PMD and Checkstyle. I'll try to enable FindBugs soon. - One of the top critical violation in JDT/Core is empty control statements,In a first time, I'd advise you to just ignore them ;) PS: Yep, I'm still hoping someone will tell Sonar how to collectI don't think this will happen soon: https://jira.codehaus.org/browse/SONAR-3872 |