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 (asf.osuosl.org: local policy)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [lang] Revisiting empty statements one more time (last time I
 promise)
Date: Mon, 4 Jul 2005 13:05:08 -0400
Message-ID: <B93830D99D595F43996A8899AEDB8F530BD4FF@ns1018.seagull.nl>
Thread-Topic: [lang] Revisiting empty statements one more time (last time I
 promise)
Thread-Index: AcWAs8ZPs/z1SF1DRDugrm5tVnLRdAAA++cw
From: "Gary Gregory" <ggregory@seagullsoftware.com>
To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>,
	"Steven Caswell" <steven.caswell@gmail.com>

Hello:

I am against using a lone ";". IMHO I think that what shows up in an AST
is irrelevant in this case and actually a problem with the source
checking tool. Let's think about the real problem, which I claim is
this:

try {
 // a=20
 // bunch=20
 // of=20
 // stuff
} catch (SomeException e) {
}

My claim: Undocumented empty blocks and especially empty catch blocks
are a BAD THING. I have Eclipse set up to give a compile warning on
"undocumented empty blocks" and on "empty statements". Of course, not
everyone uses Eclipse and whatever source-checking we use tools will not
have the same features as Eclipse.

What you really want, I claim, is this:

} catch (SomeException e) {
  // We do nothing here because the try block checked
  // the widget and logged an error in the fizbang.
}

Allowing the following is no good IMO as there is no explanation:

} catch (SomeException e) {
 ;
}

And this is no good either IMO:

} catch (SomeException e) {
  ;
  // We do nothing here because the try block checked
  // the widget and logged an error in the fizbang.
}

I want a source checking tool to tell me about undocumented empty blocks
because that is a maintenance problem. As long as there is no comment,
there is a problem IMO. Allowing solo-; is just plain old confusing to
me and does NOT add any value to the source.

As I've stated before, because some tools need to have the source
massaged a certain way is not a good reason to muck up the source, it
just points to a deficiency in the tool.

I hope the above convinces folks too ;-)

Gary

> -----Original Message-----
> From: Steven Caswell [mailto:steven.caswell@gmail.com]
> Sent: Monday, July 04, 2005 9:17 AM
> To: Jakarta Commons Developers List
> Subject: [lang] Revisiting empty statements one more time (last time I
> promise)
>=20
> Gary and Stephen (and anyone else who might care ;)
>=20
> I'd like to take one more stab at convincing you guys that an empty
> statement denoted by a semicolon would be a better approach to
> indicate no action than just using a comment. I promise I'll move on
> if this is not convincing enough.
>=20
> So here we go:
> - Empty statement is defined by the language so while it may look odd
> it is in fact a valid Java statement
> - Since it is a legal Java statement, it is parsable and shows up in
> ASTs. Comments are discarded and do not show up in ASTs
> - Any tool that uses an AST approach to examining source constructs
> (such as PMD) can be told to look for and handle an empty statement.
> Tools that use ASTs cannot be told to look for comments.
>=20
> IMHO, having the statement parsable and recognizable by tools gives
> the most flexibility at a pretty small price. The empty statement
> doesn't affect logic at all, and doesn't affect performance in the
> tests I've done. It seems a small price to pay (a bit of adjustment in
> reading the code) for the benefit.
>=20
> If a line with a single semicolon is not acceptable, is there some
> other parsable construct that would be?
>=20
> Thanks for the indulgence.
>=20
> --
> Steven Caswell
> steven.caswell@gmail.com
>=20
> Take back the web - http://www.mozilla.org
>=20
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>=20


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