My early return style is based on the general pattern:
if (something_unusual1)
return error
if (something_else_unusual)
return error
return success
In thinking this way it is hard to argue that return success is
a side-effect. If it is not an error and success thing, then the
argument is weaker (though if you substiture error=specific and
success=general it again seems ok to me).
The refactoring argument is valid, but if the method is "right-sized"
then this is a small point because the method is small and the cost of
changing the code is also small. Noticing that you replaced n-1
returns with method calls but missed the last one hopefully is pretty
rare. Also I think you generally need to add a temporary variable
in that scenario. If so you will need to explicitly do something with
that var (like return it at the end of the method).
This mostly just boils down to style...I just thought I would
mention where I am sitting on this (in case anyone cares :)). I suspect
me and David are in the same camp ... but I would hate to speak on his
behalf :)
-Tom
On Mon, 23 Jan 2006, Charles O Nutter defenestrated me:
>
> 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
--
+ http://www.tc.umn.edu/~enebo +---- mailto:[EMAIL PROTECTED] ----+
| Thomas E Enebo, Protagonist | "Luck favors the prepared |
| | mind." -Louis Pasteur |
-------------------------------------------------------
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
