I'll explain why I don't like either version and then move on..
With your two ways of doing things, it is much more complicated to do
something other than return in the future. Lets say that some day,
instead of doing a return we want to call another method (or some
other side effect). Using my version, you simply replace the return
with the new operation. If any one of the if/elseif/else blocks is
left off,as you both have done, you must do additional work to ensure
the return at the bottom does not fire in the new fall-through
behavior.
My rule of thumb is that instructions that should never execute
together during the course of a method should be separated into
different blocks. Since we should never see two returns in a given
method, they should be separated. Doing things that way allows for
replacing any one of the returns with any piece of code in the future
without modifying the other returns.
Using the side effect that a return ends a method and just expecting
future developers to be cognizant of this fact is a recipe for
trouble. Leaving that last return statement hanging off the end is
very much akin to allowing case statements to fall through on one
another, as in this example:
switch (x) {
case 1:
return a;
case 2:
return b;
}
If these returns later are removed or replaced, suddenly the cases
will fall through on one another, as they will in your versions of
if/elseif/else.
I can understand wanting to eliminate what seems like an extraneous
else block, but they are not extraneous: they make it very clear that
block B is expected to run INSTEAD OF block A. That's not immediately
apparent in your two examples, and so future developers must do extra
work to avoid fall-through bugs. The fact that a return is what's
executed as the result of a condition check is irrelevant, since that
can--and will--change in the future.
- Charlie
On 1/23/06, David Corbin <[EMAIL PROTECTED]> wrote:
> > nit:
> >
> > if (a)
> > return
> > else if (b)
> > return
> > else
> > return
> >
> > Should lop off the else:
> >
> > if (a)
> > return
> > else if (b)
> > return
> >
> > return
>
> Should lop off ALL the elses.
> if (a)
> return
> if (b)
> return
> return
>
> >
> > Other than that it looks good...
> >
> > -Tom
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
> for problems? Stop! Download the new AJAX search engine that makes
> searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
> _______________________________________________
> Jruby-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/jruby-devel
>
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642
_______________________________________________
Jruby-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/jruby-devel
