Most of these guidelines came from COBOL which has a bunch of "features"
that are a compiler writer's nightmare and a maintenance person's
opportunity for eternal employment.
COBOL is organized in paragraphs, which are sets of "sentences" (which
most of us would call statements).
Paragraphs are a group of sentences that have a label that function sort
of like a subroutine. I can't remember the exact syntax, but given
Another piece of this program can say
And s1 will execute and the return. There is no return statement; it
just knows to return.
The program can say:
Call P2 through P4
And s2, s3, and s4 will execute in that order.
The program can say
Call P1 through P4
Call P2 through P5
And execution will be s1, s2, s3, s4, s2, s3, s4, s5. There are still
no returns, but the compiler just knows to return after s4 the first
time and after s5 the second time. Needless to say, this can cause
maintenance nightmares. Programming languages like this require
external coding standards, which caused coding standards departments to
grow in large companies. Today they justify their existence by creating
standards where they really aren't needed, but the bosses all remember
when they were needed.
How do you enforce "only one return" in a language with exceptions?
From: Discussion of advanced Java topics.
[mailto:ADVANCED-JAVA@DISC...] On Behalf Of Bob Lee
Sent: Wednesday, January 16, 2008 10:10 AM
To: ADVANCED-JAVA@DISC... Subject: Re: [ADVANCED-JAVA] Multiple returns vs. Single exit
To add my 2 cents, I think having a single return makes a lot of sense
in C (perhaps where the rule carries over from), but it makes no sense
in Java at all. Just the opposite actually. Prohibiting multiple returns
in Java is downright dangerous. Setting a variable which you return once
at the end of a method puts you at risk of returning null when you
forget to set the return value or of setting the result more than once
and ignoring all but the last, two things the Java compiler can easily
detect if you'd just use multiple returns.
Also, exceptions force you think in terms of multiple exit points
Multiple returns make code more readable (no extraneous variables),
easier to follow. The same things that make it easy for a compiler to
follow make it easier for me to follow, too. "Oh, it must return
here--there's no chance execution can continue and return a different
result later in the method."
I've heard some people argue that having a variable makes it easier to
check it in a debugger but modern debuggers should enable you to see set
a method exit breakpoint and see the result.