I'm a beginning programmer studying computer science and I've been told many times that using a return statement in a loop is not a good programming habit and should be avoided. Nowadays, I read a lot of code in the Java library to learn how everything works and I'm surprised to see that return statements in loop are everywhere.

Does anyone could explain me why using return statements in loops should be avoided?

Thanks!

• java

Most people like to look at a method and assume a single point of exit. When you interpolate returns in the middle of loops it breaks up the flow a bit and jars this assumption. That's why many will make the "not clean" argument. There's really nothing dirty about it, but it forces the "human" reader of the program to dig deeper into the method to get a clearer understanding of its flow. Anything you can do to reduce the amount of mental deducing people have to do to understand the flow of your logic is considered a good thing.

If I could glance at a method without reading through its internals while getting an overall general understanding of what it does and where it exits then the author did a good job. Trouble arises when a method, which means well initially, grows over time and forces maintainers to juggle multiple states mentally in an exercise to understand it.

A good example is the classic guard clause which is considered good practice by some. It's a way of checking the state or a parameter for validity before continuing. If a method is given the wrong stuff then we don't want to continue. See this fake code:

public void doSomethingCool(Object stuff) {
  if(weWereNotExpectingThis(stuff)) return; //guard clause

  while(somethingHappens()) {
      doSomethingCool();
  }
  return;
}

Somebody comes along and says, "hey cool! We it's ok to use return statements in the middle of methods!" They make changes and it becomes:

public void doSomethingCool(Object stuff) {
  if(weWereNotExpectingThis(stuff)) return; //guard clause

  while(somethingHappens()) {
    if(somthingHasChanged()) return; //because my team likes early exits, Yay!
    else {
      doSomethingCool();
    }
  }
  return;
}

Still not too shabby, but more and more changes go in and you end up with this:

public void doSomethingCool(Object stuff) {
  if(weWereNotExpectingThis(stuff)) return; //guard clause

  while(somethingHappens()) {
    if(somthingHasChanged()) return;
    else if(weDetectNewInput()) {
      doSomethingCool();
    } else {
      doSomethingBoring();
      if(weDetectCoolInput()) {
        doSomethingCool();
        continue;
      }
      return;
    }
  }
  return;
}

Now you see where this is going. It is difficult to understand where we jump or what's going on at a single glance.

It all boils down to "clean code". That statement means different things to different people. Having one return statement at the bottom of a method is considered clean; that is subjective.

That said, methods can have multiple return statements and still be considered clean. It all depends on the tolerance of you and your team, and more importantly, your senior developers consider clean.

It's hard to quantify when you cross the line between acceptable return habits and unreadable/bug-prone code. A method that is arranged as follows

method {

 if(!x) return;

  for(...) {
    if (x && y) return

    for(...) {
        if (z) return;
    }
  }

  if (a) return;

  ...
  return;
}

is pretty much not clean no matter how you look at it.

In other words, too many return statements is a code-smell that possible the code in question needs another look

The reason return statements in loops have long been discouraged is because of a paradigm called structured programming, which basically means that the flow of execution within a program should be simple and easily followed from anywhere. At the time, GOTO was still in widespread use and was making a nightmare of code readability; as part of the backlash against it, it was often said that every block of code should have only one exit point, and the only jumps should be in conditional branches, loops, and function calls. Many people still believe this, and consequently dislike break statements, exceptions, and return statements in loops.

My own view is that it's more important to be able to understand what a particular chunk of code does than to be able to follow its exact flow of execution. (I often program in functional languages, and try to write my code in a functional style even when I'm not.) As such, I think return statements in loops are fine. It's ultimately a matter of taste.

Since I can't yet comment on other answers, I'm forced to post a new one. I would be very careful about saying that any philosophy is "always" correct. It's all about trade-offs. If adding a second return statement helps you to avoid unnecessary use of break statements and boolean flags to manage your program flow, it is probably the right thing to do.

However, others commenters are correct in suggesting that a web of return statements, breaks, and flags are a "code smell" -- see if your methods can be broken down into smaller, more modular pieces.

Those who adhere to the "single return" religion will go to great lengths to break out of loops cleanly, setting flags to indicate that it is time to return.

The best way to take such admonitions is to think about whether there is a good reason to return prematurely, or whether it is indicating sloppiness in thinking about how to structure the code.

If the objective is clean code and readability, IMHO the best approach is quit a function on the spot i.e. return in any place meeting a condition instead of having a single return in the end.

And this is perhaps not obvious in trivial examples of functions but in functions that do really complicated work, for me 1)it is easier to understand what is going on 2) it is easier to read 3) IMO it is less error prone- many times there has been a bug detected and a fix is needed ASAP. If you keep one return in the end, I have seen many times that a "quick and dirty" fix may break the code.

But this is my personal opinion.

In the olden days it could confuse compilers and the VM, not so much anymore so it's generally a safe practice. I think people also make the general 'poor practice' argument that if your a truly good programmer you'll find a more elegant way to do the same thing.

Cheers

I think the reason many people consider it cleaner ( and safer style ) is; as functions get more and more complicate ( which they often do as applications grow ), exit points in the middle of the function can be harder to trace, can become confusing and can lead to subtle bugs.

As with all 'rules' though, there are exceptions and cases where a return in the middle of a function is way cleaner than the likely if ( !error ) blocks that might result from waiting until the end.