[hibernate-dev] Code style and whitespaces

Steve Ebersole steve at hibernate.org
Wed Jul 3 08:58:04 EDT 2013


Well the trouble is that the "don't double up parens without spaces" rule
does not exist.  I guess you and Davide could tackle that with y'alls
regex-fu though :)

Tbh for me I think we should be looking at long parameter lists, both in
terms if validating their use and how they are expressed.  We have lots of
mixed styles there in ORM code.
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