On Oct 18, 2006, at 4:38 PM, Robert Greig wrote:
On 18/10/06, Steve Vinoski <[EMAIL PROTECTED]> 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
