Hi Ben and everyone who has replied,
Makes sense. Thanks for the input. I understand better now when the
usage of ‘return’.
I appreciate your help.
Regards,
– Tito
Arlen Christian Mart C. wrote:
On Sat, 2007-10-20 at 09:23 +0900, Pat M. wrote:
You’re doing great up until
but even that is considered bad programming practice (functions should have
only one exit).
which is just ridiculous.I concur. There’s nowhere that says that functions should have just one
exit - it doesn’t necessarily make for bad style, or code noise.
error, section 4.13.2, Return
Types and Values:
“AV Rule 113 (MISRA Rule 82, Revised)
Functions will have a single exit point.
Rationale: Numerous exit points tend to produce functions that are both
difficult to understand and analyze.
Exception: A single exit is not required if such a structure would
obscure or otherwise significantly complicate (such as the introduction
of additional variables) a function’s control logic. Note that the usual
resource clean-up must be managed at all exit points.”
This is from a (heavily referenced) C++ style guide, specifically for
code written for the Joint Strike Fighter. I’m no C++ expert, but I’m
led to believe that having more than one exit point in a function in C++
can lead to resource release problems. As such, it would have a clear,
practical effect there. Also, C++ functions tend to be longer (in pure
LOCs) than Ruby methods, so structural complexity is more of a barrier
to comprehension. If you google for “single-entry, single-exit” you’ll
find more references to this style and where it comes from - typically
high-reliability embedded system design, as far as I can tell.
It’s less of a problem in Ruby, I think, mainly because of the
expressiveness and the presence of GC.
Hi,
On Sat, 2007-10-20 at 18:56 +0900, Alex Y. wrote:
“AV Rule 113 (MISRA Rule 82, Revised)
Functions will have a single exit point.
Rationale: Numerous exit points tend to produce functions that are both
difficult to understand and analyze.
Exception: A single exit is not required if such a structure would
obscure or otherwise significantly complicate (such as the introduction
of additional variables) a function’s control logic. Note that the usual
resource clean-up must be managed at all exit points.”
I think we’re both in agreement and not. Particularly, the exception -
if it would obscure/complicate the control logic.
Typical C++ programming tendencies, however, should make the matter of
resource releasing a non-issue; objects are typically passed in by
reference (cleanup takes place lower in the stack) or are instantiated
in the function itself (and are automatically destructed on function
exit/exception conditions). Some people tend to use pointers and
new/delete for everything, and that’s when you get issues with exit
points like this.
It’s less of a problem in Ruby, I think, mainly because of the
expressiveness and the presence of GC.
Still, I think you’re right about it being a lesser problem in Ruby, and
in the end it may just come down to style, yet again. Readable code is
achievable both ways, I believe, but it may be more effort in some cases
with several exit points.
Arlen
On Sat, 20 Oct 2007 18:56:20 +0900, Alex Y. wrote:
On Sat, 2007-10-20 at 09:23 +0900, Pat M. wrote:
I concur. There’s nowhere that says that functions should have just one
exit - it doesn’t necessarily make for bad style, or code noise.
http://www.research.att.com/~bs/JSF-AV-rules.pdf, section 4.13.2, Return
Types and Values:
Single-exit actually used to be standard practice, back in the days of
“structured programming”. I’m surprised to see it’s still around, but I
suppose AT&T has a point - in procedural languages, if you have multiple
returns in a function, you could forget to release the appropriate
resources each time. And C++, which has no GC, isn’t immune to that.
Personally, I’ve never had a problem forgetting to release the right
resources, because any time I cut and paste a return statement, I copy
the
whole block above it too that releases all the resources. Easy.
I much prefer what I call “straight line” programming - keep on exiting
at
errors. It’s the difference between this:
if file_exists
if open
if lines_to_read
if read_doesnt_fail
if not_a_comment
process_line
end
else
log_an_error
close_the_File
end
else
log_were_done
close_the_file
end
else
log_an_error
end
else
log_an_error
end
and this:
unless file_exists
log_an_error
return
end
unless open
log_an_error
return
end
unless lines_to_read
log_were_done
close_the_file
return
end
unless read_doesnt_fail
log_an_error
close_the_file
return
end
if not_a_comment
process_line
end
Which would YOU rather maintain? For one thing, I didn’t even realize I
forgot to create a loop to read the file until I got through refactoring
it
into the second form. To me, the readability makes it less likely, not
more, that I will forget to release resources.
And if you’re really worried about it, you can always wrap a function
that
DOES have early returns inside a function that doesn’t, and give the
responsibility for resource management to the outer function. I’ve done
that a lot.
I’ve seen programs (this week!) in the first form where the routine is
hundreds of lines. If you don’t have a code-folding editor, it’s nearly
impossible to figure out what the logic really is, and where the
if/elses
match up. Doubly so on an 80x25 non-resizable screen where all the
indents
make the lines impossibly short.