[java] code style

[Steve Vinoski <vi...@iona.com>]

I think I may have briefly mentioned this before, but as part of my  
maven work I tried running code style checking tools, and all I can  
say is "Yikes!" There were many errors because the Qpid Java code  
doesn't follow industry-standard (Sun) coding style guidelines.

Is there a good reason for this? I don't want to open the can of  
worms that typically accompanies coding style questions, but I can't  
think of any good reason why Qpid should diverge from well-accepted  
industry standards.

Should it be corrected?

My opinion of the answer to the second question is that yes, it  
should be corrected. The reason is that it follows the principle of  
least surprise for developers joining the project, makes it easier  
for people to work on code written by others, and makes it easier for  
tools and IDEs to deal with the code. Once the code is fixed, we can  
easily enforce coding style in our build rules if we so choose.

Thoughts?

--steve

Re: [java] code style

[Steve Vinoski <vi...@iona.com>]

On Oct 19, 2006, at 6:09 AM, Robert Greig wrote:

> On 19/10/06, Robert Greig <ro...@gmail.com> wrote:
>> Yes, we do have a detailed document which I will put on the wiki this
>> week. We should have made this available earlier.
>
> http://cwiki.apache.org/confluence/display/qpid/Java+Coding+Standards

Excellent!

thanks,
--steve

Re: [java] code style

[Robert Greig <ro...@gmail.com>]

On 19/10/06, Robert Greig <ro...@gmail.com> wrote:
> Yes, we do have a detailed document which I will put on the wiki this
> week. We should have made this available earlier.

http://cwiki.apache.org/confluence/display/qpid/Java+Coding+Standards

RG

Re: [java] code style

[Robert Greig <ro...@gmail.com>]

On 18/10/06, Steve Vinoski <vi...@iona.com> wrote:

> I agree, but you're missing an extremely critical point: the Sun
> style is publicly documented on the web. Am I to guess what the rules
> are for the JPMC coding style used on this code? Without a document
> somewhere either in the project itself or on the wiki that explains
> exactly what the rules are for the style we're using, we might as
> well have no coding style whatsoever.

Yes, we do have a detailed document which I will put on the wiki this
week. We should have made this available earlier.

> Also, assuming we're not changing the current style, I'd like to have
> not only that document that explains the style rules, but I'd like to
> put together and enforce checkstyle rules to ensure consistency
> across the Java codebase, just as Alan's trying to do in the C++ code.

Absolutely I 100% agree we should enforce the rules - when anyone
joins my team they get a copy of the standards document to read and
are expected to abide by it. We can also make the code formatting rule
files for the popular IDEs available for download.

RG

Re: [java] code style

[Steve Vinoski <vi...@iona.com>]

On Oct 18, 2006, at 5:33 PM, Robert Greig wrote:

> On 18/10/06, Steve Vinoski <vi...@iona.com> wrote:
>> What percentage of all the Java projects out there use coding
>> guidelines other than the Sun guidelines? I would guess it's very
>> very small, far less than 1%.
>
> Is that a guess? Do you have any evidence to back that up?

Well, my sentence above does use the phrase "I would guess"... ;-)

> I have just looked at a few Apache projects. Examples of ones that do
> *not* follow the Sun standards (or at least appear not to based on a
> viewing of some randomly selected files) are BCEL, Cactus, Commons
> Configuration, ECS. I only looked at about 8 or 9 projects so that is
> a rate of around 50% (in an admittedly very small sample space).

I don't know that reviewing random open source projects is the best  
way to determine this, as many seem to be internally inconsistent  
with respect to coding style because they don't enforce it with  
automated rules.

>> Except that when I'm working on Qpid I have to remember to use the
>> right settings, which are different than all other Java projects I've
>> ever worked on...
>
> My IDE of choice (Intellij) allows me to configure the coding standard
> on a per-project basis.

IMO, nobody should ever be forced to have to rely on an IDE to get  
things like this right.

>> >> Should it be corrected?
>> >
>> > You mean "changed". Corrected implies it is broken in some way.
>>
>> I think it's broken in the sense that it's a deviation that adds
>> needless complication to Qpid development.
>
> Only if you happen to work in an environment where everyone else uses
> the standard you like.
>
>> This has nothing to do with personal preference -- I personally can
>> adapt to any style. This has to do with putting artificial hurdles in
>> the way of building the Qpid Java community. If 99+% of Java
>> developers expect to follow the Sun guidelines, then why make them
>> jump through hoops to work on Qpid?
>
> That 99% number again. My scan of other projects shows a wide variety
> of styles being adopted. This is just change for change's sake. For
> every person who likes it there is likely to be someone who dislikes
> it.
>
> As I said, with coding standards I think it is important that we have
> a standard and that it is enforced.

I agree, but you're missing an extremely critical point: the Sun  
style is publicly documented on the web. Am I to guess what the rules  
are for the JPMC coding style used on this code? Without a document  
somewhere either in the project itself or on the wiki that explains  
exactly what the rules are for the style we're using, we might as  
well have no coding style whatsoever.

Also, assuming we're not changing the current style, I'd like to have  
not only that document that explains the style rules, but I'd like to  
put together and enforce checkstyle rules to ensure consistency  
across the Java codebase, just as Alan's trying to do in the C++ code.

--steve

Re: [java] code style

[Robert Greig <ro...@gmail.com>]

On 18/10/06, Steve Vinoski <vi...@iona.com> wrote:
> What percentage of all the Java projects out there use coding
> guidelines other than the Sun guidelines? I would guess it's very
> very small, far less than 1%.

Is that a guess? Do you have any evidence to back that up?

I have just looked at a few Apache projects. Examples of ones that do
*not* follow the Sun standards (or at least appear not to based on a
viewing of some randomly selected files) are BCEL, Cactus, Commons
Configuration, ECS. I only looked at about 8 or 9 projects so that is
a rate of around 50% (in an admittedly very small sample space).

> Except that when I'm working on Qpid I have to remember to use the
> right settings, which are different than all other Java projects I've
> ever worked on...

My IDE of choice (Intellij) allows me to configure the coding standard
on a per-project basis.

> >> Should it be corrected?
> >
> > You mean "changed". Corrected implies it is broken in some way.
>
> I think it's broken in the sense that it's a deviation that adds
> needless complication to Qpid development.

Only if you happen to work in an environment where everyone else uses
the standard you like.

> This has nothing to do with personal preference -- I personally can
> adapt to any style. This has to do with putting artificial hurdles in
> the way of building the Qpid Java community. If 99+% of Java
> developers expect to follow the Sun guidelines, then why make them
> jump through hoops to work on Qpid?

That 99% number again. My scan of other projects shows a wide variety
of styles being adopted. This is just change for change's sake. For
every person who likes it there is likely to be someone who dislikes
it.

As I said, with coding standards I think it is important that we have
a standard and that it is enforced.

RG

Re: [java] code style

[Steve Vinoski <vi...@iona.com>]

On Oct 18, 2006, at 4:38 PM, Robert Greig wrote:

> On 18/10/06, Steve Vinoski <vi...@iona.com> wrote:
>> I think I may have briefly mentioned this before, but as part of my
>> maven work I tried running code style checking tools, and all I can
>> say is "Yikes!" There were many errors because the Qpid Java code
>> doesn't follow industry-standard (Sun) coding style guidelines.
>
> Sun offers one set of Java coding standards. It is certainly not  
> the only one.
>
> For example, if you look at various other Apache projects (e.g. MINA)
> you will see they have not adopted the Sun guidelines.
>
> A quick google yielded this alternative to the Sun guidelines:
> http://www.infospheres.caltech.edu/resources/code_standards/ 
> java_standard.html
>
> And there are many others.

What percentage of all the Java projects out there use coding  
guidelines other than the Sun guidelines? I would guess it's very  
very small, far less than 1%.

>> Is there a good reason for this? I don't want to open the can of
>> worms that typically accompanies coding style questions, but I can't
>> think of any good reason why Qpid should diverge from well-accepted
>> industry standards.
>
> The coding standard is the one used by a large group within JPMC and
> was adopted by the project from the start. I believe that as long as
> the code adopts *a* standard (that is not eccentric), and it is
> applied consistently it is serving its purpose.

Except that when I'm working on Qpid I have to remember to use the  
right settings, which are different than all other Java projects I've  
ever worked on...

>> Should it be corrected?
>
> You mean "changed". Corrected implies it is broken in some way.

I think it's broken in the sense that it's a deviation that adds  
needless complication to Qpid development.

>> My opinion of the answer to the second question is that yes, it
>> should be corrected. The reason is that it follows the principle of
>> least surprise for developers joining the project, makes it easier
>> for people to work on code written by others, and makes it easier for
>> tools and IDEs to deal with the code.
>
> All the IDEs I have used (Eclipse, Intellij, Netbeans) can quite
> easily support the coding standard in the project.
>
>> Once the code is fixed, we can
>> easily enforce coding style in our build rules if we so choose.
>
> I suggest we enforce the style that is already there. Changing all the
> code just introduces a large pile of "false diffs" and for no reason
> other than personal preference.

This has nothing to do with personal preference -- I personally can  
adapt to any style. This has to do with putting artificial hurdles in  
the way of building the Qpid Java community. If 99+% of Java  
developers expect to follow the Sun guidelines, then why make them  
jump through hoops to work on Qpid?

--steve

Re: [java] code style

[Robert Greig <ro...@gmail.com>]

On 18/10/06, Steve Vinoski <vi...@iona.com> wrote:
> I think I may have briefly mentioned this before, but as part of my
> maven work I tried running code style checking tools, and all I can
> say is "Yikes!" There were many errors because the Qpid Java code
> doesn't follow industry-standard (Sun) coding style guidelines.

Sun offers one set of Java coding standards. It is certainly not the only one.

For example, if you look at various other Apache projects (e.g. MINA)
you will see they have not adopted the Sun guidelines.

A quick google yielded this alternative to the Sun guidelines:
http://www.infospheres.caltech.edu/resources/code_standards/java_standard.html

And there are many others.

> Is there a good reason for this? I don't want to open the can of
> worms that typically accompanies coding style questions, but I can't
> think of any good reason why Qpid should diverge from well-accepted
> industry standards.

The coding standard is the one used by a large group within JPMC and
was adopted by the project from the start. I believe that as long as
the code adopts *a* standard (that is not eccentric), and it is
applied consistently it is serving its purpose.

> Should it be corrected?

You mean "changed". Corrected implies it is broken in some way.

> My opinion of the answer to the second question is that yes, it
> should be corrected. The reason is that it follows the principle of
> least surprise for developers joining the project, makes it easier
> for people to work on code written by others, and makes it easier for
> tools and IDEs to deal with the code.

All the IDEs I have used (Eclipse, Intellij, Netbeans) can quite
easily support the coding standard in the project.

>Once the code is fixed, we can
> easily enforce coding style in our build rules if we so choose.

I suggest we enforce the style that is already there. Changing all the
code just introduces a large pile of "false diffs" and for no reason
other than personal preference.

RG