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.
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
