Sonar analysis of OpenJDK 7 available

[Stuart Marks]

On 11/28/11 3:21 PM, Mario Torre wrote:
> Il giorno 28/nov/2011, alle ore 19:05, Kelly O'Hair ha scritto:
>> On Nov 24, 2011, at 12:36 AM, Roman Kennke wrote:
>> But I would argue that there are many many more important quality issues than extra parens in code,
>> and we should focus on the more important issues.
>> When you include ALL quality issues like this one in a report, it creates a HUGE pile of issues that
>> I consider an unfair representation of the code, and a daunting situation to deal with.
>>
>> My issue is one of priorities, we should focus on the more dangerous quality issues here,
>> and not many style issues are high priority in my opinion.
>
> I also find return (true) more difficult to read ;) (oh, well, I'm the guy who still asks people to stay
> within the 80 columns...) but I agree there are better priorities; I also find this kind of results a bit polluting,
> since they may actually create background noise that will make more important things less obvious.
>
> However, all considered, those extremely low priority warnings maybe still good to have around, since they
> are easy task to be picked by students or people that want to contribute but actually don't have a full view
> of the platform; in other words they can lower significantly the entry barrier to contribution, which is a good thing
> imho.
>
> I think the best solution is what has been suggested elsewhere in this thread, to have a set of defined rules, or
> perhaps even more than one set. I would be cool to create a list of "easy" tasks (like other projects like Gnome or
> LibreOffice have) so that people can start cleaning up the code.

Coincidentally, we've just announced an effort to clean up javac warnings. See 
this recent announcement [1] which I also just forwarded to this list. Cleaning 
up warnings can be one of these "easy" tasks for code cleanup.

A javac warning is sometimes but not always an indication of a quality problem. 
Having lots of noisy warnings tends to obscure the important warnings. IMHO 
cleaning up javac warnings is a higher priority than cleaning up code style 
warnings, since a javac warning is more likely to point out an actual bug.

s'marks


[1] http://mail.openjdk.java.net/pipermail/jdk8-dev/2011-November/000302.html