| Re: [platform-releng-dev] Progress with Platform Build and Sonar |
|
Real questions:
* What about equals without hashCode ? That's a very common performance trap, what do you think about those reports? * About the empty blocks, I'm not a JVM expert but, wouldn't some compiler keep evaluation the condition for a "if (condition) { /* nothing */ }" ? Debate on benefits of static analysis continuing: Looking at 100+ issues, I found one mildly relevant issueThat's already cool to spot one bug before it is delivered. This Sonar repo already led somewhere (once in 1 day). So we need project specific rules.Probably, however, I don't know how to make this happen. From my build guy POV, I think this + usage of git submodules call for project-specific build. I tend to preach a very mild variant to this to JDT users.Some users (like me) do like warnings from JDT and FindBugs. It's just a matter of getting used to it, but FindBugs and JDT became some kind of instant reviewer of what I write. In the end, I write less bugs, although I have many warnings on my java code. I do hope that some people understand that static analysis tool is not just another metric to tweak. That's the kind of people that are usually targeted by static analysis tools. So, what's the magic comment to silence a warning after deciding There is probably a way to achieve that, but I'm not a Sonar/Checkstyle/PMD hacker, I'm a vanilla user and don't know most of the magic. The risk with tweaking rules for the project inside Sonar is that someone who is only focusing on the metric decides to ignore some useful rules. When this is done, the rules gets forgotten and can be broken silently. Overall, I'm not forcing anyone to look at it, it's just a tool that is there, and free to use. -- |