Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Received-SPF: pass (hermes.apache.org: local policy)
Content-class: urn:content-classes:message
Subject: RE: [lang] Code clean up of "return (value);"?
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Date: Sat, 9 Oct 2004 16:01:26 -0400
Message-ID: <2B64219028BBFF48B3CC957EF10B58FE2978A8@ns1018.SSSI.seagull.nl>
Thread-Topic: [lang] Code clean up of "return (value);"?
Thread-Index: AcSt5GMiMn/tm6rWS5OG8zSlKep9vAAVVEVg
From: "Gary Gregory" <ggregory@seagullsoftware.com>
To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>

> I always tend to have the extra brackets in return statements for
> expressions. It just clarifies the look for me.

I guess I cannot argue on personal preferences; we all like a different
dose of syntactic sugar ;-)

> I don't believe we should change existing code, just let each class
evolve
> according to each developer. The only time we should change formatting
is
> if
> the current code is way far from out standards.

An issue, I think, is that the evolution one way or another has to be
somewhat consistent and the use of "return e;" vs. "return (e);" is not
consistent even within single classes.=20

For example, you'll find plenty of classes (ex: IntRange) where one
method uses "(e)" (ex: containsInteger(int)) and the very next method in
the source (containsRange(Range)) does not. This is not so nice, which
is why my personal preference is to use the simpler syntax, which is
clearer IMHO.

FYI, some other classes with mixed usage: JVMRandom, DoubleRange,
NumberRange, FloatRange, etc.

Gary

> -----Original Message-----
> From: Stephen Colebourne [mailto:scolebourne@btopenworld.com]
> Sent: Saturday, October 09, 2004 02:49
> To: Jakarta Commons Developers List
> Subject: Re: [lang] Code clean up of "return (value);"?
>=20
> I always tend to have the extra brackets in return statements for
> expressions. It just clarifies the look for me.
>=20
> I don't believe we should change existing code, just let each class
evolve
> according to each developer. The only time we should change formatting
is
> if
> the current code is way far from out standards.
>=20
> Stephen
>=20
> ----- Original Message -----
> From: "Gary Gregory" <ggregory@seagullsoftware.com>
> I agree with Craig WRT to non-return expressions (if, while) and I
also
> personally prefer being more explicit in if statements rather than
> relying solely on operator priorities. This is why I am only
commenting
> on return statements.
>=20
> In the case of return statements, I do not see any value in extra
> parentheses. So, for [lang] I am pushing for their removal. I have
> already done so for [codec] but I do not want to propose anything for
> other projects as I am active only on [lang] and [codec].
>=20
> Gary
>=20
> > -----Original Message-----
> > From: Craig McClanahan [mailto:craigmcc@gmail.com]
> > Sent: Friday, October 08, 2004 17:36
> > To: Jakarta Commons Developers List
> > Subject: Re: [lang] Code clean up of "return (value);"?
> >
> > On Fri, 8 Oct 2004 17:15:08 -0700 (PDT), David Graham
> > <grahamdavid1980@yahoo.com> wrote:
> > > This shows up in Struts quite a bit and I think Craig uses this
> > > convention.  I don't personally care for it because Java needs
less
> > syntax
> > > rather than more :-).
> > >
> >
> > It's a personal preference of mine to clearly highlight "this is an
> > expression".  I wouldn't be bothered by seeing it go away from
return
> > statements -- but I'm still going to put in "redundant" parentheses
in
> > my "if" statements rather than relying on the priority of the
various
> > operators :-).
> >
> > > David
> >
> > Craig
> >
> >
---------------------------------------------------------------------
> > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>=20
>=20
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>=20
>=20
>=20
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org