[hibernate-dev] Code style and whitespaces

Steve Ebersole steve at hibernate.org
Wed Jul 3 09:05:58 EDT 2013


I vote for having spaces in the method/constructor usages.

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.

That's just my feelings though..
 On Jul 3, 2013 7:52 AM, "Gunnar Morling" <gunnar at hibernate.org> wrote:

> 2013/7/3 Steve Ebersole <steve at 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 at 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 at 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 at hibernate.org>
>>>> wrote:
>>>>
>>>> > +1 for  'catch ( IllegalArgumentException e )' - using white spaces
>>>> >
>>>> > On 3 Jan 2013, at 11:07 AM, Sanne Grinovero <sanne at 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 at lists.jboss.org
>>>> > > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>> >
>>>> > _______________________________________________
>>>> > hibernate-dev mailing list
>>>> > hibernate-dev at lists.jboss.org
>>>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>> >
>>>> _______________________________________________
>>>> hibernate-dev mailing list
>>>> hibernate-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>
>>>
>>>
>


More information about the hibernate-dev mailing list