[lang] Revisiting empty statements one more time (last time I promise)
Gary and Stephen (and anyone else who might care ;) 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. 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. 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. If a line with a single semicolon is not acceptable, is there some other parsable construct that would be? Thanks for the indulgence. -- Steven Caswell [EMAIL PROTECTED] Take back the web - http://www.mozilla.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [lang] Revisiting empty statements one more time (last time I promise)
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
// bunch
// of
// 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:[EMAIL PROTECTED]
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)
Gary and Stephen (and anyone else who might care ;)
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.
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.
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.
If a line with a single semicolon is not acceptable, is there some
other parsable construct that would be?
Thanks for the indulgence.
--
Steven Caswell
[EMAIL PROTECTED]
Take back the web - http://www.mozilla.org
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang] Revisiting empty statements one more time (last time I promise)
How about:
try
{
...
} catch (SomeException ignored) {
// We do nothing here because the try block checked
// the widget and logged an error in the fizbang.
}
i.e. use a special variable name that can then be checked in the compiled code.
S.
On 7/4/05, Gary Gregory [EMAIL PROTECTED] wrote:
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
// bunch
// of
// 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:[EMAIL PROTECTED]
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)
Gary and Stephen (and anyone else who might care ;)
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.
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.
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.
If a line with a single semicolon is not acceptable, is there some
other parsable construct that would be?
Thanks for the indulgence.
--
Steven Caswell
[EMAIL PROTECTED]
Take back the web - http://www.mozilla.org
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [lang] Revisiting empty statements one more time (last time I promise)
} catch (SomeException ignored) {
Interesting thought! Somehow, I do not think that checkstyle can do
that. Can it?
Gary
-Original Message-
From: sebb [mailto:[EMAIL PROTECTED]
Sent: Monday, July 04, 2005 10:23 AM
To: Jakarta Commons Developers List
Subject: Re: [lang] Revisiting empty statements one more time (last
time I
promise)
How about:
try
{
...
} catch (SomeException ignored) {
// We do nothing here because the try block checked
// the widget and logged an error in the fizbang.
}
i.e. use a special variable name that can then be checked in the
compiled
code.
S.
On 7/4/05, Gary Gregory [EMAIL PROTECTED] wrote:
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
// bunch
// of
// 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:[EMAIL PROTECTED]
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)
Gary and Stephen (and anyone else who might care ;)
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.
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.
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.
If a line with a single semicolon is not acceptable, is there some
other parsable construct that would be?
Thanks for the indulgence.
--
Steven Caswell
[EMAIL PROTECTED]
Take back the web - http://www.mozilla.org
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang] Revisiting empty statements one more time (last time I promise)
It could possible be done using the GenericIllegalRegexp check. I'm
not a regexp guru so I'm not sure if an appropriate regexp could be
written, but knowing how powerful regexps are I wouldn't be surprised.
On 7/4/05, Gary Gregory [EMAIL PROTECTED] wrote:
} catch (SomeException ignored) {
Interesting thought! Somehow, I do not think that checkstyle can do
that. Can it?
Gary
-Original Message-
From: sebb [mailto:[EMAIL PROTECTED]
Sent: Monday, July 04, 2005 10:23 AM
To: Jakarta Commons Developers List
Subject: Re: [lang] Revisiting empty statements one more time (last
time I
promise)
How about:
try
{
...
} catch (SomeException ignored) {
// We do nothing here because the try block checked
// the widget and logged an error in the fizbang.
}
i.e. use a special variable name that can then be checked in the
compiled
code.
S.
On 7/4/05, Gary Gregory [EMAIL PROTECTED] wrote:
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
// bunch
// of
// 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:[EMAIL PROTECTED]
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)
Gary and Stephen (and anyone else who might care ;)
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.
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.
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.
If a line with a single semicolon is not acceptable, is there some
other parsable construct that would be?
Thanks for the indulgence.
--
Steven Caswell
[EMAIL PROTECTED]
Take back the web - http://www.mozilla.org
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED
RE: [lang] Revisiting empty statements one more time (last time I promise)
Whoa... RE's, very fancy! :-)
I am not being really serious: An even more complicated solution would
be to use whatever Eclipse uses to check for such things.
G
-Original Message-
From: Steven Caswell [mailto:[EMAIL PROTECTED]
Sent: Monday, July 04, 2005 11:57 AM
To: Jakarta Commons Developers List
Subject: Re: [lang] Revisiting empty statements one more time (last
time I
promise)
It could possible be done using the GenericIllegalRegexp check. I'm
not a regexp guru so I'm not sure if an appropriate regexp could be
written, but knowing how powerful regexps are I wouldn't be surprised.
On 7/4/05, Gary Gregory [EMAIL PROTECTED] wrote:
} catch (SomeException ignored) {
Interesting thought! Somehow, I do not think that checkstyle can do
that. Can it?
Gary
-Original Message-
From: sebb [mailto:[EMAIL PROTECTED]
Sent: Monday, July 04, 2005 10:23 AM
To: Jakarta Commons Developers List
Subject: Re: [lang] Revisiting empty statements one more time
(last
time I
promise)
How about:
try
{
...
} catch (SomeException ignored) {
// We do nothing here because the try block checked
// the widget and logged an error in the fizbang.
}
i.e. use a special variable name that can then be checked in the
compiled
code.
S.
On 7/4/05, Gary Gregory [EMAIL PROTECTED] wrote:
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
// bunch
// of
// 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:[EMAIL PROTECTED]
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)
Gary and Stephen (and anyone else who might care ;)
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.
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.
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.
If a line with a single semicolon is not acceptable, is there
some
other parsable construct that would be?
Thanks for the indulgence.
--
Steven Caswell
[EMAIL PROTECTED]
Take back the web - http://www.mozilla.org
-
To unsubscribe, e-mail:
[EMAIL PROTECTED]
For additional commands, e-mail
