Hi Markus,
I guess the replies we have seen so far indicate how sensitive a
subject coding conventions can be.
The convention regarding braces around blocks has been around the
TopLink code base since before the part of TopLink that is now TopLink
Essentials was added to the GlassFish project. As you can see, there
are varied opinions about that kind of a convention. In the absence of
an overwhelmingly strong argument, or overwhelming support for a changed
convention, this coding convention is not likely to change and in fact,
changing coding conventions in the middle of a project is likely
problematic.
It is unfortunately that your opinion of how open this project is is
tied so strongly to the coding conventions. Personally, I would tie my
opinion to how open the system for suggesting features and enhancements
was and how open the community was to code changes and design
suggestions from community members.
-Tom
Markus KARG wrote:
>Tom,
>
>so actually this is not an open source project in the typical way of an
>open community (= everything gets discussed and decided by democratic
>rules), but in fact it is centrally controlled by Oracle and Sun but we
>- the independent contributors - have to follow the provided, fixed
>rules but we may not discuss them?
>
>If this is the truth, my enthusiasm in contributing to GF just has been
>fallen to nearly zero. :-(
>
>Regards
>Markus
>
>Tom Ware wrote:
>
>
>>Hi Markus,
>>
>> I am trying to stay out of the coding style debate since for some
>>people it is a very personal thing.
>>
>> In this case, our enforced coding style requires braces around all
>>blocks. I strongly believe this makes the code easier to read. I
>>understand that people use other styles (and feel strongly about
>>them), but all code contributed to the entity-persistence module will
>>be required to follow that convention.
>>
>>-Tom
>>
>>Markus KARG wrote:
>>
>>
>>
>>>Jakub,
>>>
>>>actually if you want to contribute to GF, you need to be a Java
>>>professional (sorry for all others, but I doubt anyone else is able to
>>>even understand what GF does). Saying that, I believe any Java
>>>professional is able to add the missing bracket. Also, since no one will
>>>write code without adding a JUnit test first (we all are professionals,
>>>remember ;-) ) one minute later JUnit will tell you that you missed the
>>>bracket, actually.
>>>
>>>Have Fun
>>>Markus
>>>
>>>Jakub Podlesak wrote:
>>>
>>>
>>>
>>>
>>>>Hi Markus,
>>>>
>>>>just a comment on (5). Please see document at
>>>>http://java.sun.com/docs/codeconv/CodeConventions.pdf
>>>>
>>>>By omitting brackets in such a code you just make the code
>>>>shorter, but certainly not better for reading, in spite what you wrote.
>>>>And you also introduce a place for potential bug.
>>>>Consider somebody wants to add a new line to such single line
>>>>statement. If there are no brackets, he/she needs to add them as
>>>>well, what
>>>>could be a problem.... and it could be very easy to oversee
>>>>missing brackets e.g where comments are heavily used.
>>>>
>>>>Have a nice day and good luck
>>>>
>>>>~Jakub
>>>>
>>>>
>>>>
>>>>On Tue, Oct 03, 2006 at 12:37:51PM +0200, Markus KARG wrote:
>>>>
>>>>
>>>>
>>>>
>>>>>(5) Do you think, Single Line Blocks are too short?
>>>>>
>>>>>Don't you like the shortness of single line blocks? Or are we all Java
>>>>>beginners? ;-) Otherwise I cannot understand why you keep writing the
>>>>>ending bracket in single-line blocks (e. g. FORs and IFs). This makes
>>>>>the code harder to read and longer than needed. Java allows omitting
>>>>>trailing brackets in single line blocks by intention, not by fault.
>>>>>;-)
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>---------------------------------------------------------------------
>>>>To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>>>For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>
>>
>>
>>
>
>
>