'Single Entry Single Exit' - Valid Or Nonsense?

Question

In a book I'm reading right now, the author suddenly started to talk about 'single entry single exit' as a principle we should follow.
Single exit was supposed to mean, that we don't have many returns in a function, but only one, at the very end, because for some reason that's better.
So this is how I might write a prime function:
def is_prime(n):
if n<2 or not n%2:
return False
if n==2:
return True
for div in range(3, sqrt(n)+1, 2):
if not n%div:
return False
return True
I'd definitely have several return points.
Whenever it's already clear that a number can never be prime, why should I stick around, store a boolean, loop nonsensically and only then return? Where's the gain?
Or rather: Isn't there a clear loss?
Not only would I end up defining useless variables, I'd run useless code, just for the sake of it.
Am I missing something? Am I not understanding the idea correctly? Or is there something to this which I just don't see yet?

Answer 1

This concept is more applicable for resource management. When you allocate some resources (like file, memory, device...) in a function you should deallocate them on exit of the function. If the function has more than one exit, you should deallocate the resources before each exit. So, your write the same piece of code many times (before each return). It is bad style and very error prone (you need make change for every deallocation part of code when your write/modify the code). So, deallocation (and allocation) of resources should be done in one place.
Single Entry Single Exit is also applicable to block of code (not for a whole function).
This concept is also used in Python but it is transprent for you, for example the 'with' statement. It is used to manage resource allocation/deallocation (by __enter__ / __exit__ methods). You usually use the 'with' statement with files (which is resources). If you return from the 'with' statement Python will automatically call the __exit__ method of a file object for you.
The 'finally' statement is another example of single exit.
If you don't need single exit (for example, you don't allocate resources) in the function you can (should) use a return statement more than one time when it enhances readability.

Answer 2

HonFu,
I have expience in programming and I usualy used SESE only where it was actually needed (resource management). Some languages have neither exception handling nor classes (like C, you can't use 'finally' or RAII).
I have never used SESE in codes like is_prime_number:
When you see the return statement at the beginning of a function you immediately understand what will be returned. Otherwise, you have to read the rest of the code to know the result. Also you have deeper nesting in this case what makes readability of the code worse.
So, if using of multiple return statemens make your code more readable and easier to understand then use them. (Of course, this is just my opinion)

Answer 3

Alright, so this is a very old idea, then? Maybe it's one of these ideas that somehow just stick around, and no one knows why.
Actually, the book teaches Java for beginners, and the first publishing was 2012. 😉
The author talks about it in different situations, for example also with goto/labels.
There I can see the danger. I mean, no one teaches these any more, or rather they say: 'It exists, but don't touch it.'
Funnily he then seems to go on applying this even to break!
Because if a loop is broken, it has two ways to exit. And this is somehow supposed to be... suspicious?
I've seen a user here propagate the idea of break and continue being 'not good', and I couldn't believe it. Now I encounter that notion again.
In a function, having one return statement is supposed to make it 'easier to read'. And from my point of view, that's just nonsense. It just blows the code up, adding lines that don't do anything. 🤔

Answer 4

I never heard about this rule but I found this: https://softwareengineering.stackexchange.com/questions/118703/where-did-the-notion-of-one-return-only-come-from
Maybe more experienced programmers can tell more about the rule but it seems:
Single entry means no alternate entry points and single exit means the method should return to one place (it has nothing to do with the number of return statements).
I guess this rule makes not really sense for java or python.
At the moment I would not know how to jump e.g. into the middle of a method. Java allows labels but the goto keyword has no function.
And the return statement jumps always to the place where the method is called. Maybe with the help of other methods it would be possible to jump somewhere else.

Answer 5

in case of python and similar languages where one can “call a function” the rule of single entry single exit is automatically enforced.
even though you have multiple return statements in the code , the called function would always return to same location where function was called from. there is no need to reduce “return “ statements to one.
Fortran, COBOL and similar languages used “go to” to jump to a different section of code and the code returned back to original location using “go to”.
it was possible for the called code to branch to different parts of calling code( bad , very bad coding practice) which was a nightmare to debug.
Now, why would some one teach that in 2012 or beyond...?. that i guess is authors privilege. it is like teaching some one to press clutch for changing gear in an automatic transmission car.

Answer 6

Single entry single exit also known as SISO is a valid recommendation for basic, fortran etc and is not applicable for python.functions

Answer 7

Denise Roßberg, interesting discussion there. It makes SESE look a bit like a largely misunderstood concept.
Single entry is a given anyway, and single return point also, in most of the languages we talk about here.
So only the point 'easier to read' remains, and that should be rather different on a case-by-case basis, right? (The prime function up there wouldn't really become simpler with a single exit.)
Labels, goto and such... tricky. Probably side-effects also fall into this. What does SESE help, when a function changes all sorts of things secretly while it runs?
Being suspicious against break... well, that goes too far, I think. Yeah, if you manage to write some quadruple loop with all sorts of special cases and flags... then the problem would be rather the messy design, not the poor little break, right? 😅
Same for functions or methods. If they are so hard to maintain if they have more than one exit... maybe they're just doing too much?

Answer 8

andriy kan, okay when some sort of resource handling is involved, I can see how it might become tricky.
If you rewrite the file-closing or heapspace-releasing part in front of every return, that gets rather uglily WET.
Probably, since we often have other, modern ways now to handle these problems, using with or finally, or RAII in C++, or garbage collection, that sort of problems don't come up as regularly.
So either multiple returns are no problem, or - if they would be - we have other tools than refactoring towards a single exit.
I got a link from a friend via DM, that also mentions the resource problem and discusses the pros and cons of different jump techniques, with the question in mind if it's implicitly clear from looking at the code where the jump goes to (like with a return statement) or ambiguous (with a goto statement).
https://en.m.wikipedia.org/wiki/Return_statement#Multiple_return_statements

Answer 9

KCSLearner why do you make a difference between the languages ?
could u explain please?

Answer 10

HonFu
I try to use only nested for loops for multidimensional arrays.
But in some cases I use a helper method to outsource the loop.
And I think a method should have only one task. Calling a helper method should be okay. But more then one helper method could be a sign that you should rework your method.
At least you would have to take care that you not end in indirect recursion.
Let A, B, C be methods:
A -> B -> A
A -> B -> C -> A
But in the end I think such a rule like single entry/single exit are maybe helpful but no dogmas. If it helps you to keep your code simple and readable, great. But I would break the rule if the code gets too complicated.

Answer 11

In french