8:56 a.m.
On 3 Jul 2013 14:06, "Steve Ebersole" <steve(a)hibernate.org> wrote:
I vote for having spaces in the method/constructor usages.
I'm not seeing the need for spaces when invoking a constructor, but I am ok
with it.
Like Gunnar (iirc) said earlier, I find having the usages be consistent
and
different from the declarations to be a simple but effective visual
clue
as
I look through the source.
I like them to be different as well, for the same reason.
like most IDEs use colours to highlight different constructs, and I
wouldn't want to change that to use a one single colour for consistency
reasons, I would not look for spacing consistency across different things.
As Davide pointed out, the formatting rules we recommended for Eclipse have
catch statements without space so I'd stick to that: consistency is not
persuading me at all.
Sanne
That's just my feelings though..
On Jul 3, 2013 7:52 AM, "Gunnar Morling" <gunnar(a)hibernate.org> wrote:
> 2013/7/3 Steve Ebersole <steve(a)hibernate.org>
>
>> The "original" rule was that parens should always be separated by
>> spaces. E.g.:
>>
>> if (isTrue ()) { ... }
>>
>> Is clearly fugly.
>>
>> if ( isTrue () ) { ... }
>>
>> To me is clearly more readable.
>>
>> Method/constructor declarations do not use spaces inside parens simply
>> because the arguments list cannot contain parens. Same for exception
>> catching btw..
>>
> Ah, I see. This reasoning makes sense, but IMO the rule is not really
> apparent, I guess one just needs to know it. I don't really mind either
> way, but at least method invocations and constructor invocations should
be
> handled consistently (i.e. both with white space following the
reasoning
> above).
>
>
>
>> On Jul 3, 2013 7:31 AM, "Gunnar Morling" <gunnar(a)hibernate.org>
wrote:
>>
>>> I'm voting for having white spaces in catch as well as constructor
>>> invocations, the reason being to ensure a consistent style with method
>>> invocations, if, while etc. I don't see an advantage in having white
space
>>> in some of these constructs but not in others.
>>>
>>>
>>> 2013/7/3 Steve Ebersole <steve(a)hibernate.org>
>>>
>>>> There is a mix in ORM as well. My vote is for no spaces inside the
>>>> parens
>>>> for catch statements. I do like the spaces for if, for, while, etc
>>>> though.
>>>> On Jul 3, 2013 5:29 AM, "Hardy Ferentschik"
<hardy(a)hibernate.org>
>>>> wrote:
>>>>
>>>> > +1 for 'catch ( IllegalArgumentException e )' - using
white spaces
>>>> >
>>>> > On 3 Jan 2013, at 11:07 AM, Sanne Grinovero
<sanne(a)hibernate.org>
>>>> wrote:
>>>> >
>>>> > > Looking at the following patch:
>>>> > >
>>>> > >
>>>> > > }
>>>> > > - catch (IllegalArgumentException e) {
>>>> > > + catch ( IllegalArgumentException e ) {
>>>> > >
>>>> > > would you consider it an improvement in terms of consistency
with
>>>> the
>>>> > > Hibernate style?
>>>> > >
>>>> > > It has always been my interpretation that we use whitespaces
inside
>>>> > > blocks, like:
>>>> > >
>>>> > >
>>>> > > if ( condition)
>>>> > > //rather than
>>>> > > if (condition)
>>>> > >
>>>> > > but we don't for constructor invocations:
>>>> > >
>>>> > > new Wrapper(type, param);
>>>> > > //rather than
>>>> > > new Wrapper( type, param );
>>>> > >
>>>> > > and we also do not (usually) for catch.
>>>> > >
>>>> > > I know that might sound like inconsistent, but the point is
>>>> > > readability: I've got used to it and I could swear that
the
>>>> *different
>>>> > > treating* helps with eyeball code scanning.. but I realize
that
>>>> could
>>>> > > be a very personal opinion.
>>>> > >
>>>> > > So since we're encoding this rule now in checkstyle, which
one
shall
>>>> > > it be for the catch statements?
>>>> > >
>>>> > > My guts vote goes to
>>>> > >
>>>> > > }
>>>> > > catch (IllegalArgumentException e) {
>>>> > > ...
>>>> > >
>>>> > > but I'd prefer to follow the convention from ORM, if you
guys
have a
>>>> > > clear rule :-)
>>>> > >
>>>> > > Cheers,
>>>> > > Sanne
>>>> > > _______________________________________________
>>>> > > hibernate-dev mailing list
>>>> > > hibernate-dev(a)lists.jboss.org
>>>> > > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>> >
>>>> > _______________________________________________
>>>> > hibernate-dev mailing list
>>>> > hibernate-dev(a)lists.jboss.org
>>>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>> >
>>>> _______________________________________________
>>>> hibernate-dev mailing list
>>>> hibernate-dev(a)lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>
>>>
>>>
>
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev