Make a break and continue if you return

I know that this issue often was discussed on several Q&A sites or community forums. But it seems to me that the discussion is about a real issue as most developer do not care about control flow.

The subject is: Why multiple "return" statements within a method or a function are bad, not in general, but most of the time. This also relates to "break" and "continue".

First of all there is a mystery about "one entry and one exit". This was really an issue when it came to structured programming. This advice is often misrepresented. It does not mean "do only have one return statement", it really means "jump to only one defined marker".

Knowing this the discussion seems to be over. But wait: This advice does adress a total other issue! It adresses an issue that we do not have today anymore because we have functions and methods. The control flow automatically jumps to the location where you called the function/method.

As the advice "single exit" does not cover "single return" in the sense it was meant for we haven't a closed case. Of course any "return" will leave the function and return to the function call. But that is not the issue. The issue is: breaking the control flow.

So what is so bad about "breaking" the control flow?

I do not pretend to write perfect code in the first place neither I will be able to improve it to perfect code after that.

Code is under continious change so most of the time you will clean it up and modify it. So in my opinion code should be easy to modify without breaking it. Yes you should have tests but that is not what I mean. You shouldn't break it the first time if you can.

There are compiler and IDE supported refactorings like extract method. I often use "extract method" to break a large method into pieces. I also often struggle with state within a large method and with "return", "break" and "continue". The problem is "extract method" will not work on code that has an intermediate "return" statements. "Extract method" will also not work within loops that use break and continue. The reason for this is that "extract method" has the precondition that it should preserve the control flow as best as it can. And it fails if the control flow breaks or jumps to locations that are outside the code to be extracted.

Often I have to reformulate the whole control flow to break a large method into smaller ones. So the time you saved in the first place with early returns others will have time consuming refactorings afterwards.

My suggestion is to have only one return statement at the end of a function or a method. Maybe you do not need it if you have little or none state to manage (so in functional programming). But as soon as you manage state control flow becomes essential. If you have a large method an you have "early returns" and you try to extract pieces of code in a separate method you will fight the same battle as they fought in the 80s with gotos.