I think it is very reasonable to have code conventions and to stick by
them. That has been true for all projects I've worked in of any
non-trivial size.
I think it is appropriate to discuss whether the existing code
conventions make sense or not, but this is likely to turn into a rathole
as code conventions are, at some level, somewhat arbitrary and personal.
Ultimately somebody (or somebodies) will need to make the call. The
only case where I personally think this would be really useful is when
discussing new language features (like annotations) or recent ones (like
generics).
FWIW, I also believe in inserting { } around all blocks. And the old
Java code convention explicitly mandates them (see
http://java.sun.com/docs/codeconv/html/CodeConventions.doc6.html#15395).
Hope this helps,
- eduard/o
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
>>
>>
>