I am currently in a beginning programming course at my University (I've got plenty of experience in the subject already, but I still have to pay for that piece of paper with time and money.) and the professor has been stressing since the beginning of the course that the break primitive that many languages provide is bad programming practice, and that many companies have policies stating that their programmers are not to use them.
Why is it considered bad practice to exit functions and loops with break primitives?

  • I suspect he means using the break statement to exit from loops, not when they form an intrinsic part of another structure like a switch statement. – James McLeod Jan 24 '15 at 3:15
  • 7
    I guess your professor is the only person who can explain his own opinions about bad practices. – Hey Jan 24 '15 at 3:18
  • Apologies, I only did just realize that my question is a bit opinionated and open ended. I just thought he might actually be right. – Torger597 Jan 24 '15 at 3:26
  • Going to rewrite my question to make it on topic. – Torger597 Jan 24 '15 at 3:30
  • 1
    It isn't considered a bad practice. – Robert Harvey Jan 24 '15 at 4:23

In switch statements, they're pretty much essential -- well, you can use extract method/class to break it down into one-line cases, but ... -- I don't think that's what your professor means.

To break from a loop is considered by some to be a goto with another name. So is returning from the middle of a method. I have even seen a similar case used against exceptions. If you think about it, it makes logical sense; all of the reasons for avoiding the use of goto would apply equally to multiple exit points from a loop or method.

All of those constructs create paths through the code that aren't linear.

But, all that said, I would argue that they each represent a place where goto could be used to improve readability (usually by decreasing indentation), so having language constructs that represent them in different ways can only be a good thing. That way, we know, when we see one of these constructs, what the code is intending to do, and we can continue to enforce a policy of not using goto.

That is, however, my opinion. I don't think everyone agrees with me. And I will agree with anyone who contends that when you come to write a break, or a mid-method return, or an exception that covers anything but an unexpected situation, you should probably have a think about better ways to code it. Just remember, such a thing doesn't always exist.

| improve this answer | |
  • Thanks. I wasn't really thinking about it from that perspective, I suppose. From a design perspective it does simplify things a bit from removing extra exit points to functions and loops. – Torger597 Jan 24 '15 at 3:36
  • @Torger597 in practice it's just a tradeoff between (slightly?) counterintuitive flow of control (in the case of break / continue / early return) and increased cyclomatic complexity, code duplication, extra temporary variables, and so on (in the opposing case). Like many things there is probably no real "best practice," just different approaches with different benefits and drawbacks. That said, break/continue might be a sign that you need to break things up into smaller functions (SRP), assuming you don't mind early returns. – Hey Jan 24 '15 at 4:18

Not the answer you're looking for? Browse other questions tagged or ask your own question.