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