At 2:42 AM -0800 3/3/06, Lars Jensen wrote:
There is no downside if the check is optional (whether it's a warning
or an error isn't crucial). Even if you import code that doesn't have
return statements, you can simply turn off the option and you're in
the same unprotected boat you are in now. One hopes that people who
publish third-party code would get into the habit of using the option.
Experience in other languages that support optional compiler
errors/warnings show that this is not the case. Many people will
simply turn them off, and as their code spreads and is used
elsewhere, this bad habit spreads as well, like a virus. As a
result, optional warnings or errors are next to useless. If
something is such a bad idea that you shouldn't do it, then it should
simply be an error, with no way to avoid it (except, of course, to
stop doing whatever that is in your code).
In addition, the approach of giving warnings that can't be turned off
but which don't stop the compile is just as bad. In this case,
people simply start ignoring the warnings. This has been shown by
careful studies, and is also supported by my own experience. Such
warnings are also useless, because if there is ever a new one you
ought to really be concerned about, you'll never notice it among the
flood of warnings you routinely ignore. Good programmers use
compiler options to turn these warnings into errors, and fix them
religiously, but this habit is hard to maintain when other people
(whose code you will eventually want to share) take the lazy way out
-- see above.
I'm a bit on the fence as to whether forcing returns is a good idea.
In particular, I don't think there should be separate rules for
events vs. other functions; events are special only in how and where
they are invoked, but in every other respect are currently like any
other method. Yet we don't want to require returns for events, since
that would cause quite a bit of grief. So my feeling is that the
current situation, where returns are optional, is probably best.
But if it is decided that this isn't true, and a function should
return a value, then it should be enforced with a perfectly ordinary
compiler error. Not something you can turn off or ignore.
Now, there is an in-between solution, which would be to have a code
analysis tool that crawls through your project (or selected parts
thereof) and reports, among other things, on possible errors. These
should be hierarchical and grouped by error, rather than by location,
so that if you know that "implicit conversion from Integer to Double"
is something you really don't care about, you can just leave that row
closed and not bother to look at the 31 cases it thinks it found.
But if you're religious about explicit returns, then you'll look at
the "Implicit return from non-empty function" line and see if it
found more than 0 cases -- and if so, twist it open to see where
those are, and fix 'em.
Why is such a code analysis tool better than warnings, you ask? Two reasons:
1. Sorting by warning type rather than by location, and making it
hierarchical, allows you to quickly focus on the ones you care about,
without actually turning off the ones you don't.
2. Having to actually run this tool means that you are likely to look
at the results -- unlike warnings, which appear every time you hit
Run and quickly train you to ignore them.
Of course, you still have the issue that different people would make
different use of such a tool, and bad habits (if ignoring these
constitutes such) would tend to spread. But I think there really are
gray cases, where a coding practice is not necessarily an error but
might be, and so an analysis tool for paranoid or bug-hunting
developers is useful. For anything else -- anything that is almost
always a mistake, for example -- it should be a true compiler error
that you can't ignore.
Oh, one more thing (can you tell I've been thinking about this for a
long time?). For any possible error, there must always be a way to
indicate to the code analysis tool (and other readers of the code)
that the developer is aware of it, and is doing whatever-it-is
intentionally. Ideally this would be something in the language
itself -- for example, an explicit way to typecast from a double to
an integer. When such is not available, at the very least there
should be some way to tag that line with a comment that makes it
clear this was intentional, and the analysis tool should see this and
stop barking about it. That way, you can reduce the number of
"possible errors" found to 0, so that any new ones jump out. (This
is more or less the same thing done by good programmers in languages
with warnings do, but a voluntary analysis tool is still preferable
for the reasons above.)
Best,
- Joe
--
Joseph J. Strout
[EMAIL PROTECTED]
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>
Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>
