Introduction Functions should have only a single entry point. We all agree on that. But some people also argue that functions should have a single exit that returns the value. More people don't seem to care enough about how their functions are organized. I think that makes functions a lot more complicated than they have to be. So let's talk about function organization and how multiple exit points can help. I'm going to use Python in the examples, but these examples apply to many other languages such as JavaScript and Ruby as well, so do keep reading.

Starting point Let's consider the following function: def process_items ( items , bar , default ): result = None if bar is not None : for item in items : if item . match == "A" : result = item . payload elif item . match == "B" : continue else : if item . other == "C" : result = item . override else : result = bar if result is not None : break else : result = "No bar" if result is None : result = default return result It's a silly function, it's a hypothetical function, but there are plenty of functions with this kind of structure. They might not be born this way, but they've certainly grown into it. I find them difficult to follow. You can recognize them by one symptom already: quite a bit of indentation. You can also recognize them by trying to trace what happens in them; notice how your working memory fills up quickly.

Extract function from loop body How would we go about refactoring it? The first step I would take is to extract the loop body into a separate function. You may say, why do so? Objections could be: The loop body isn't reused in multiple places, so why should it be a function?

You have to manage function parameters whereas before all was conveniently available in the body of foo . That is all so, but let's do it anyway and see what happens, and then get back to this in the end: def process_items ( items , bar , default ): result = None if bar is not None : for item in items : result = process_item ( item , bar ) if result is not None : break else : result = "No bar" if result is None : result = default return result def process_item ( item , bar ): if item . match == "A" : result = item . payload elif item . match == "B" : result = None else : if item . other == "C" : result = item . override else : result = bar return result We've had to extract two parameters - item and bar . It turns out process_item doesn't care about default . We've had to convert the continue to a result = None to keep things working properly, as now we always run into the if result is not None check whereas before we did not.

Multiple exit points We notice that result is only touched once in each code path in process_item . This means we can convert the function to use multiple exit points with the return statement, so let's do that: def process_item ( item , bar ): if item . match == "A" : return item . payload elif item . match == "B" : return None else : if item . other == "C" : return item . override else : return bar

Convert to guard clauses That's still more complicated than it should be. Since we have early exit points, we can get rid of the elif and else clauses: def process_item ( item , bar ): if item . match == "A" : return item . payload if item . match == "B" : return None if item . other == "C" : return item . override else : return bar Some indentation is gone, which is a good sign. And we see another else we can get rid of now: def process_item ( item , bar ): if item . match == "A" : return item . payload if item . match == "B" : return None if item . other == "C" : return item . override return bar

Pay attention to None I think the return None case is special, so let's move that up. That's safe as A and B for item.match are mutually exclusive and this function has no side effects: def process_item ( item , bar ): if item . match == "B" : return None if item . match == "A" : return item . payload if item . other == "C" : return item . override return bar This function is now a lot more regular. If you read it past return None you can forget about the case where item.match == "B" , and then forget about the case where item.match == "A" , and then forget about the case where item.other == "C" . In the original version that was a lot harder to see.

Why pay attention to None? This last reorganization of the guard clauses may seem like a useless action. But I pay special attention to None (or null or undefined or however your language may name the absence of value). If you organize the guard clauses that deal with None to come earlier, it makes your functions more regular and thus more easy to read. It also triggers you to consider whether perhaps item.match == "B" is something you can handle at the call site, which can lead to further refactorings. Later we'll consider that further in a bonus refactoring. Languages that have an Option or Maybe type such as Haskell and Rust make this more obvious and have special ways to handle these cases -- the language forces you. TypeScript also tracks tracks null/undefined in its type system. But in many other languages, such as Python, we're on our own. But we certainly still have to pay attention to None . See also my the Story of None.

Back to process_items Now let's look at the process_items function again: def process_items ( items , bar , default ): result = None if bar is not None : for item in items : result = process_item ( item , bar ) if result is not None : break else : result = "No bar" if result is None : result = default return result

Multiple exit points Let's first transform this so we return early when we can: def process_items ( items , bar , default ): result = None if bar is not None : for item in items : result = process_item ( item , bar ) if result is not None : break else : return "No bar" if result is None : return default return result

Flip condition to create a guard We can see clearly that "No bar" is returned if bar is None , so let's flip that condition: def process_items ( items , bar , default ): result = None if bar is None : return "No bar" else : for item in items : result = process_item ( item , bar ) if result is not None : break if result is None : return default return result We can now see the else clause is not needed anymore, so let's unindent the for loop. We also move result = None below that guard clause for bar is None , as it's not needed until that point: def process_items ( items , bar , default ): if bar is None : return "No bar" result = None for item in items : result = process_item ( item , bar ) if result is not None : break if result is None : return default return result So it turns out in the rest of the function we can completely forget about bar being None . That's good. Maybe that guard can even be removed if we can somehow guarantee the non-None nature of bar at the call site. But we can't determine that in this limited example. Let's go on refactoring this function a bit more.

Turn loop break into early return We take a look at the break . If result is not None , we break. Then after that we check if result is None . This can only happen if the loop never breaked. If the loop did break we end up returning result . So we can just as well do the return result immediately in the loop: def process_items ( items , bar , default ): if bar is None : return "No bar" result = None for item in items : result = process_item ( item , bar ) if result is not None : return result if result is None : return default return result Let's look at the bit of code past the end of the loop again. We know that result has to be None if it reaches there. It's initialized to None and the loop returns early if it's ever not None . So why do we even check whether result is None anymore? We can simply always return default : def process_items ( items , bar , default ): if bar is None : return "No bar" result = None for item in items : result = process_item ( item , bar ) if result is not None : return result return default We have no more business setting result to None before the loop starts. It's a local variable within the loop body now: def process_items ( items , bar , default ): if bar is None : return "No bar" for item in items : result = process_item ( item , bar ) if result is not None : return result return default

In review Let's look at where we started and ended. We started with this: def process_items ( items , bar , default ): result = None if bar is not None : for item in items : if item . match == "A" : result = item . payload elif item . match == "B" : continue else : if item . other == "C" : result = item . override else : result = bar if result is not None : break else : result = "No bar" if result is None : result = default return result And we ended with this: def process_items ( items , bar , default ): if bar is None : return "No bar" for item in items : result = process_item ( item , bar ) if result is not None : return result return default def process_item ( item , bar ): if item . match == "B" : return None if item . match == "A" : return item . payload if item . other == "C" : return item . override return bar The second version is much easier to follow, I think. (it's also a few lines less code, but that's not that important.)

In defense of single-use functions So we created a process_item function even though we only use it in one place. Earlier asked why you would do such a thing. What benefits does that have? We could convert the function to use guard clauses, removing a level of nesting and letting us come up with followup refactoring steps that simplified our code.

It's clearer to see what actually really matters in the loop and what doesn't, as it's spelled out in the parameters of the function.

We gave what happens in the for loop a name. process_item doesn't say much in this case, but in a real-world code base your function name can help you read your code more easily.

loop a name. doesn't say much in this case, but in a real-world code base your function name can help you read your code more easily. Maybe we'll end up reusing it after all! It also can lead to interesting future refactorings as it's easier to see patterns. If you do OOP for instance, you may end up with a group of functions that all share the same set of arguments and this would suggest creating a class with methods. But let's leave OOP be and consider None .

A possible followup refactoring We know bar cannot be None when process_item is called -- see our guard clause. If we know (or find a way to guarantee) that item.payload and item.override can never be None either, we can do this: def process_items ( items , bar , default ): if bar is None : return "No bar" for item in items : if item . match != "B" : return process_item ( item , bar ) return default def process_item ( item , bar ): if item . match == "A" : return item . payload if item . other == "C" : return item . override return bar Which then leads to the question whether we should filter items with item.match != "B" before they even reach process_items in the first case -- another potential refactoring. All of these refactorings require knowledge of what's impossible in the code and the data -- its invariants. We don't know this in this contrived example. But in a real code base, you can find out. A static type system can help make these invariants explicit, but that doesn't mean that in a dynamically typed language we should forget about them. Yes, I'm saying the same as what I said about None before -- whether something is nullable is an important example of an invariant.