My boss keeps mentioning nonchalantly that bad programmers use break and continue in loops.

I use them all the time because they make sense; let me show you the inspiration:

function verify(object) {
    if (object->value < 0) return false;
    if (object->value > object->max_value) return false;
    if (object->name == "") return false;

The point here is that first the function checks that the conditions are correct, then executes the actual functionality. IMO same applies with loops:

while (primary_condition) {
    if (loop_count > 1000) break;
    if (time_exect > 3600) break;
    if (this->data == "undefined") continue;
    if (this->skip == true) continue;

I think this makes it easier to read & debug; but I also don't see a downside.

  • 2
    Doesn't take much to forget which one does what. – user1249 Mar 15 '11 at 16:02
  • 60
    No. Neither is goto. Knowing when to use them is the key. They are tools in the toolbox. You use them when they provide clear & succinct code. – orj Mar 15 '11 at 20:41
  • 71
    I cannot voice my support for this style of coding strongly enough. Multiple levels of nested conditionals are so much worse than this approach. I'm usually not militant about coding style, but this is almost a deal-breaker for me. – Emil H Mar 16 '11 at 5:39
  • 11
    Obviously your boss doesn't write (enough) code. If he did, he would know that all keywords (yes, even goto) are useful in some cases. – sakisk Mar 26 '11 at 9:39
  • 60
    Bad programmers use break and continue doesn't mean that good programmers don't. Bad programmers use if and while as well. – mouviciel Nov 27 '13 at 14:22

21 Answers 21


When used at the start of a block, as first checks made, they act like preconditions, so it's good.

When used in the middle of the block, with some code around, they act like hidden traps, so it's bad.

| improve this answer | |
  • 6
    @Klaim: It can be argued that any routine that has several exit points is a poorly-factored routine. A properly factored routine should do one thing and one thing only. – bit-twiddler Mar 16 '11 at 13:45
  • 85
    @bit-twiddler: this is a very C-ish mindset. A temporary variable can be modified later on, so a single typo 20 lines down from here could erase that carefully crafted result. An immediate return (or break, or continue) however is extremely clear: I can stop reading now because I know it can't possibly be modified further down. It's good for my little brain, really makes trudging through the code easier. – Matthieu M. Mar 17 '11 at 19:00
  • 18
    @Matthieu I agree. Exit a block when you receive a result that satisfies the block's purpose. – Evan Plaice Mar 19 '11 at 5:48
  • 9
    @bit-twiddler - the single-exit-point principle is separate from the single-responsibility-principle. I don't agree that checking is always separate from acting WRT the single responsibility. In fact "single responsibility" always strikes me as a subjective term. For example, in a quadratic-solver, should calculating the discriminant be a separate responsibility? Or can the whole quadratic formula be a single responsibility? I'd argue that it depends on whether you have a separate use for the discriminant - otherwise, treating it as a separate responsibility is probably excessive. – Steve314 Oct 6 '11 at 8:35
  • 11
    That answer is a rule of thumb, not a hard rule. It works in most cases, feel free to break it if it make sense in your context. – Klaim Jul 29 '14 at 23:13

You could read Donald Knuth's 1974 paper Structured Programming with go to Statements, in which he discusses various uses of the go to that are structurally desirable. They include the equivalent of break and continue statements (many of the uses of go to in there have been developed into more limited constructs). Is your boss the type to call Knuth a bad programmer?

(The examples given interest me. Typically, break and continue are disliked by people who like one entry and one exit from any piece of code, and that sort of person also frowns on multiple return statements.)

| improve this answer | |
  • 8
    Most of the people who like functions and procedures to have single entry and exit points grew up on Pascal. Pascal was not the first language that I learned, but it had a profound impact on how I structure code to this day. People always comment on how easy it is to read my Java code. That's because I avoid multiple exits points as well as intermixing declarations with code. I try my best to declare every local variable used in a method at the top of the method. This practice avoids code ramble by forcing me to keep methods succinct. – bit-twiddler Mar 15 '11 at 15:37
  • 5
    Pascal also had nested functions. Just sayin'... – Shog9 Mar 15 '11 at 17:32
  • 6
    From what I remember, back in the day, the main reason that people didn't like multiple return statements in functions was because debuggers didn't handle them properly. It was a real pain to set a breakpoint at the end of a function but you never hit it because of an earlier return statement. For every compiler I use nowadays that is no longer an issue. – Dunk Mar 15 '11 at 19:16
  • 28
    @bit-twiddler: I'm not so sure about that. I'm still using Pascal today, and I generally regard "single entry single exit," or at least the single-exit part of it, as cargo cult programming. I just consider Break, Continue and Exit as tools in my toolbox; I use them where it makes the code easier to follow, and don't use them where it would make things harder to read. – Mason Wheeler Mar 15 '11 at 21:32
  • 2
    @bit-twiddler: amen to that. I'll also add that once you're down to blocks that fit easily on-screen, multiple exit points become far less troublesome. – Shog9 Mar 17 '11 at 4:52

I do not believe they are bad. The idea that they are bad comes from the days of structured programming. It is related to the notion that a function must have a single entry point and a single exit point, i. e. only one return per function.

This makes some sense if your function is long, and if you have multiple nested loops. However, your functions should be short, and you should wrap loops and their bodies into short functions of their own. Generally, forcing a function to have a single exit point can result in very convoluted logic.

If your function is very short, if you have a single loop, or at worst two nested loops, and if the loop body is very short, then it is very clear what a break or a continue does. It is also clear what multiple return statements do.

These issues are addressed in "Clean Code" by Robert C. Martin and in "Refactoring" by Martin Fowler.

  • 14
    "Make your functions small. Then make them smaller" -Robert C. Martin. I found that this works surprisingly well. Every time you see a block of code in a function that needs a comment explaining what it does, wrap it into a separate function with a descriptive name. Even if it is only a few lines, and even if it is only used once. This practice eliminates most of the issues with break/continue or multiple returns. – Dima Mar 15 '11 at 15:13
  • 2
    @Mikhail: Cyclomatic complexity is generally pretty strongly correlated with SLOC, which means that the advice can be simplified to "don't write long functions". – John R. Strohm Mar 19 '11 at 16:54
  • 3
    The idea of a single exit point is widely misinterpreted. Once upon a time, functions did not have to return their caller. They could return to some other spot. This was commonly done in assembly language. Fortran had a special construct for this; you could pass in a statement number preceded by ampersand CALL P(X, Y, &10), and in case of error, the function could pass control to that statement, instead of returning to the point of the call. – kevin cline Oct 6 '11 at 0:42
  • @kevincline as seen with Lua, for instance. – Qix - MONICA WAS MISTREATED Dec 1 '14 at 3:41
  • 1
    @cjsimon you got it. Not only functions should be small. Classes should be small too. – Dima Jun 1 '18 at 20:27

Bad programmers speak in absolutes (just like Sith). Good programmers use the clearest solution possible (all other things being equal).

Using break and continue frequently makes code hard to follow. But if replacing them makes the code even harder to follow, then that's a bad change.

The example you gave is definitely a situation where the breaks and continues should be replaced with something more elegant.

  • Yeah, I exaggerated the number of conditions to provide examples of cases to exit. – Mikhail Mar 15 '11 at 19:17
  • 9
    What is an example of the replacement code you've suggested? I thought it was a rather reasonable example of guard statements. – simgineer Aug 5 '15 at 20:12
  • It seems to me that "the clearest solution possible" is always... possible? How could there not be a "clearest" solution? But then, I am not one for absolutes, so maybe you are right. – user251748 Jun 6 '17 at 18:29
  • @nocomprende I'm not sure what you're getting at. The "possible" here doesn't indicate that the best solution doesn't exist -- only that perfect, ultimate clarity is not a thing. It's subjective, after all. – Matthew Read Jun 6 '17 at 18:48
  • I'd like to see what the more elegant replacement would be too. I've been programming for a bit now and I'm at a loss. – phorgan1 Jun 16 at 4:53

Most people think it's a bad idea because the behaviour isn't easily predictable. If you're reading through the code and you see while(x < 1000){} you assume it's going to run until x >= 1000...But if there are breaks in the middle, then that doesn't hold true, so you can't really trust your looping...

It's the same reason people don't like GOTO: sure, it can be used well, but it can also lead to godawful spaghetti code, where the code leaps randomly from section to section.

For myself, if I was going to do a loop that broke on more than one condition, I'd do while(x){} then toggle X to false when I needed to break out. The final result would be the same, and anyone reading through the code would know to look more closely at things that switched the value of X.

  • 2
    +1 very well said, and +1 (if I could do another) for the while(notDone){ } approach. – FrustratedWithFormsDesigner Mar 15 '11 at 15:20
  • 5
    Mikhail: The issue with break is that the final condition for the loop is never simply stated in one place. That makes it difficult to predict the post-condition after the loop. In this trivial case (>= 1000) it's not hard. Add many if-statements and different levels of nesting it it can become very, very difficult to determine the post-condition of the loop. – S.Lott Mar 15 '11 at 15:46
  • S.Lott hit the nail squarely on the head. The expression that controls iteration should include every condition that must be met in order to continue iteration. – bit-twiddler Mar 17 '11 at 14:19
  • 9
    Replacing break; with x=false; does not make your code more clear. You still have to search the body for that statement. And in the case of x=false; you'll have to check that it doesn't hit a x=true; further down. – Sjoerd Mar 17 '11 at 14:57
  • 15
    When people say "I see x and I assume y, but if you do z that assumption doesn't hold" I tend to think "so don't make that stupid assumption". Many people would simplify that to "when I see while (x < 1000) I assume it will run 1000 times". Well, there's many reasons why that's false, even if x is initially zero. For example, who says x is incremented precisely once during the loop, and never modified in any other way? Even for your own assumption, just because something sets x >= 1000 doesn't mean the loop will end - it may be set back in range before the condition gets checked. – Steve314 Oct 6 '11 at 9:57

Yes you can [re]write programs without break statements (or returns from the middle of loops, which do the same thing). But you may have to introduce additional variables and/or code duplication both of which typically make the program harder to understand. Pascal (the programming language) was very bad especially for beginner programmers for that reason. Your boss basically wants you to program in Pascal's control structures. If Linus Torvalds were in your shoes, he would probably show your boss the middle finger!

There's a computer science result called the Kosaraju's hierarchy of control structures, which dates back to 1973 and which is mentioned in Knuth's (more) famous paper on gotos from 1974. (This paper of Knuth was already recommended above by David Thornley, by the way.) What S. Rao Kosaraju proved in 1973 is that it's not possible to rewrite all programs that have multi-level breaks of depth n into programs with break depth less than n without introducing extra variables. But let's say that's just a purely theoretical result. (Just add a few extra variables?! Surely you can do that to please your boss...)

What's far more important from a software engineering perspective is a more recent, 1995 paper by Eric S. Roberts titled Loop Exits and Structured Programming: Reopening the Debate (http://cs.stanford.edu/people/eroberts/papers/SIGCSE-1995/LoopExits.pdf). Roberts summarizes several empirical studies conducted by others before him. For example, when a group of CS101-type students were asked to write code for a function implementing a sequential search in an array, the author of the study said the following about those students who used a break/return/goto to exit the from the sequential search loop when the element was found:

I have yet to find a single person who attempted a program using [this style] who produced an incorrect solution.

Roberts also says that:

Students who attempted to solve the problem without using an explicit return from the for loop fared much less well: only seven of the 42 students attempting this strategy managed to generate correct solutions. That figure represents a success rate of less than 20%.

Yes, you may be more experienced than CS101 students, but without using the break statement (or equivalently return/goto from the middle of loops), eventually you'll write code that while nominally being nicely structured is hairy enough in terms of extra logic variables and code duplication that someone, probably yourself, will put logic bugs in it while trying to follow your boss' coding style.

I'm also gonna say here that Roberts' paper is far more accessible to the average programmer, so a better first read than Knuth's. It's also shorter and covers a narrower topic. You could probably even recommend it to your boss, even if he is the management rather than the CS type.

  • 2
    Though structured programming was my approach for many years, in the last few have switched to entirely using explicit exits at first possible opportunity. This makes faster execution and almost eliminates logic errors that used to result in endless loops (hanging). – DocSalvager Oct 17 '15 at 13:25

I don't consider using either of these bad practice, but using them too much within the same loop should warrant rethinking the logic being used in the loop. Use them sparingly.

| improve this answer | |
  • :) yes, the example I provided was conceptual – Mikhail Mar 15 '11 at 15:04

The example you gave doesn't need breaks nor continues:

while (primary-condition AND
       loop-count <= 1000 AND
       time-exec <= 3600) {
   when (data != "undefined" AND
           NOT skip)

My ‘problem’ with the 4 lines in your example is that they are all on the same level but they do different things: some break, some continue... You have to read each line.

In my nested approach, the more deeper you go, the more ‘useful‘ the code becomes.

But, if deep inside you'd find a reason to stop the loop (other than primary-condition), a break or return would have it's use. I'd prefer that over the use of an extra flag that is to be tested in the top-level condition. The break/return is more direct; it better states the intent than setting yet another variable.

  • +1 But actually your < comparisons need to be <= to match the OPs solution – El Ronnoco Mar 16 '11 at 11:39
  • 3
    In most cases, if one is so deep that one needs to use break/return to manage flow control, one's function/method is too complex. – bit-twiddler Mar 17 '11 at 14:30

The "badness" is dependent on how you use them. I typically use breaks in looping constructs ONLY when it will save me cycles that can't be saved through a refactoring of an algorithm. For instance, cycling through a collection looking for an item with a value in a specific property set to true. If all you need to know is that one of the items had this property set to true, once you achieve that result, a break is good to terminate the loop appropriately.

If using a break won't make the code specifically easier to read, shorter to run or save cycles in processing in a significant manner, then it's best not to use them. I tend to code to the "lowest common denominator" when possible to make sure that anyone who follows me can easily look at my code and figure out what's going on (I am not always successful at this). Breaks reduce that because they do introduce odd entry/exit points. Misused they can behave very much like an out of whack "goto" statement.

| improve this answer | |
  • I agree with both points! As far as your second point - I think it's easier to follow my original post because it reads like English. If you have a combination of conditions in 1 if statement, then it's almost a deciphering to figure out what has to happen for the if to execute true. – Mikhail Mar 15 '11 at 15:15
  • @Mikhail: The samples you provided are a little altruistic for specific realism. As I see it, those samples are clear, concise, easier to read. Most loops are not like that. Most loops have some sort of other logic they are performing and potentially much more complicated conditionals. It's in these cases where break/continue may not be the best usage because it does muddy up the logic when read. – Joel Etherton Mar 15 '11 at 15:17

Absolutely not... Yes the use of goto is bad because it deteriorates the structure of your program and also it is very difficult to understand the control flow.

But use of statements like break and continue are absolutely necessary these days and not considered as bad programming practice at all.

And also not that difficult to understand the control flow in use of break and continue. In constructs like switch the break statement is absolutely necessary.

  • 2
    I haven't used "continue" since I first learned C in 1981. It is an unnecessary language feature, as the code that is bypassed by the continue statement can be wrapped by a conditional control statement. – bit-twiddler Mar 15 '11 at 15:24
  • 13
    I prefer to use continue in those cases since it makes sure that my code doesn't become arrow code. I hate arrow code more than goto type statements. I also read it as, "if this statement is true, skip the rest of this loop and continue with the next iteration." Very useful when it's at the very beginning of a for loop (less useful in while loops). – jsternberg Mar 15 '11 at 15:48
  • @jsternberg For for the win! :-) – Notinlist Sep 26 '12 at 12:24

The essential notion comes from being able to semantically analyze your program. If you have a single entry and a single exit, the math needed to denote possible states is considerably easier than if you have to manage forking paths.

In part, this difficulty reflects out into being able to conceptually reason about your code.

Frankly, your second code is not obvious. What is it doing? Does continue 'continue', or does it 'next' the loop? I have no idea. At least your first example is clear.

| improve this answer | |
  • When I work in a project that manager obligate to use them, I had to use a flowchart to remember its use, and the several exit paths, did make more confusing th code... – umlcat Mar 15 '11 at 18:15
  • your "Frankly" comment is syntactic -- "next" is a perl thing; normal languages use "continue" to mean "skip this loop" – Mikhail Mar 15 '11 at 18:42
  • @Mik, maybe "skip this iteration" would be a better description. Yours truly, Dr. I. M. Pedantic – Pete Wilson Mar 15 '11 at 19:05
  • @Mikhail: Sure. But when one works in lots of languages, it can lead to errors when the syntax isn't common between languages. – Paul Nathan Mar 15 '11 at 19:59
  • But math is not programming. Code is more expressive than math. I get that single-entry/single-exit may make flowcharts look nicer but at what expense (Ie. where break/return can make code perform better)? – Evan Plaice Mar 19 '11 at 7:34

I would replace your second code snippet with

while (primary_condition && (loop_count <= 1000 && time_exect <= 3600)) {
    if (this->data != "undefined" && this->skip != true) {

not for any reasons of terseness - I actually think this is easier to read and for someone to understand what is going on. Generally speaking the conditions for your loops should be contained purely within those loop conditions not littered throughout the body. However there are some situations where break and continue can help readability. break moreso than continue I might add :D

  • WHile I disagree with, "I actually think this is easier to read" this does accomplish the exact same purpose as the code above. I've never really thought of 'break' as a short-circuit operator until now but it makes perfect sense. As for,"Generally speaking the conditions for your loops should be contained purely within those loop conditions", what do you do when you're processing a foreach loop since there's really no way to insert conditional logic in the loop definition? – Evan Plaice Mar 26 '11 at 8:56
  • @Evan The condition is not applicable to a foreach loop as this will just iterate every item in a collection. A for loop is similar in that it should not have a conditional end point. If you do need a conditional end point then you need to use a while loop. – El Ronnoco Jul 25 '11 at 13:06
  • 1
    @Evan I do see your point though - ie 'what if you need to break out of a foreach loop?' - Well, there should only be one break maximum in my opinion from the loop. – El Ronnoco Jul 25 '11 at 13:10

I disagree with your boss. There are proper places for break and continue to be used. In fact the reason that execeptions and exception handling were introduced to modern programming languages is that you can't solve every problem using just structured techniques.

On a side note I don't want to start a religious discussion here but you could restructure your code to be even more readable like this:

while (primary_condition) {
    if (loop_count > 1000) || (time_exect > 3600) {
    } else if ( ( this->data != "undefined") && ( !this->skip ) ) {
       ... // where the real work of the loop happens

On another side note

I personally dislike the use of ( flag == true ) in conditionals because if the variable is a boolean already, then you are introducing an additional comparison that needs to happen when the value of the boolean has the answer you want - unless of course you are certain that your compiler will optimize that extra comparison away.

  • I have waffled on this question for years. Your way ( 'if ( flag ) {...}' ) is a lot more terse and maybe it looks more 'professional' or 'expert'. But, ya' know, it often means that a reader/maintainer has to interrupt herself briefly to recall what the construct means; and to be sure of the sense of the test. Currently, I am using 'if ( flag == true) { ... }' just because it seems to be better documentation. Next month? Quien sabe? – Pete Wilson Mar 15 '11 at 19:02
  • 2
    @Pete - The term is not terse but elegant. You can waffle all you want, but if you are worried that the reader/maintainer doesn't understand what a boolean is or what the terse/elegant terminology means is then maybe you better hire some smarter maintainers ;-) – Zeke Hansell Mar 15 '11 at 19:30
  • @Pete, I also stand by my statement about the generated code. You are doing one more compare by comparing a flag to a constant value before evaluating boolean value of the expression. Why make it harder than it has to be, the flag variable already has the value you want! – Zeke Hansell Mar 15 '11 at 19:33
  • +1 good job. Definitely a lot more elegant than the former example. – Evan Plaice Mar 19 '11 at 7:36

I agree with your boss. They are bad because they produce methods with high cyclomatic complexity. Such methods are difficult to read and difficult to test. Fortunately there's an easy solution. Extract the loop body into a separate method, where the "continue" becomes "return". "Return" is better because after "return" it's over -- there's no worries about the local state.

For "break" extract the loop itself into a separate method, replacing "break" with "return".

If the extracted methods require a large number of arguments, that's an indication to extract a class -- either collect them into a context object.

| improve this answer | |

I think it's only a problem when nested deeply inside multiple loops. It's hard to know which loop you are breaking to. It might be difficult to follow a continue also, but I think the real pain comes from breaks - the logic can be difficult to follow.

| improve this answer | |
  • 2
    Actually, it's easy to see if you indent properly, have the semantics of those statements internalized and aren't too sleepy. – user7043 Mar 15 '11 at 14:56
  • @delnan - that's a lot of assumptions ;) – davidhaskins Mar 15 '11 at 14:56
  • 2
    Yeah, especially the last. – Michael K Mar 15 '11 at 14:57
  • Well, #1 is required for serious programming anyway, #2 is to be expected from everyone called programmer, and #3 is quite useful in general ;) – user7043 Mar 15 '11 at 14:57
  • Some languages (only scripting that I know) support break 2; for others, i guess temporary bool flags are used – Mikhail Mar 15 '11 at 15:03

As long as they're not used as disguised goto like in the following example :

      if (foo)
             /*** code ***/

      if (bar)
             /*** code ***/
} while (0);

I'm fine with them. (Example seen in production code, meh)

  • Would you recommend for cases like these to create functions? – Mikhail Mar 28 '11 at 17:03
  • Yes and if not possible, a plain goto. When I see a do, I think repetition, not context to simulate jump. – SuperBloup Mar 29 '11 at 8:18
  • oh I agree, i was just asking how you'd do it :) Computer scientists do it repeatedly – Mikhail Mar 29 '11 at 14:09

I don't like either of these styles. Here's what I would prefer:

function verify(object)
    if not (object->value < 0) 
       and not(object->value > object->max_value)
       and not(object->name == "") 
         do somethign important
    else return false; //probably not necessary since this function doesn't even seem to be defined to return anything...?

I really don't like using return to abort a function. It feels like an abuse of return.

Using break also is not always clear to read.

Better yet might be:

notdone := primarycondition    
while (notDone)
    if (loop_count > 1000) or (time_exect > 3600)
       notDone := false; 
        skipCurrentIteration := (this->data == "undefined") or (this->skip == true) 

        if not skipCurrentIteration
           do something

less nesting and the complex conditions are refactored into variables (in a real program you'd have to have better names, obviously...)

(All above code is pseudo-code)

  • 11
    You would really prefer 3 levels of nesting over what I typed above? – Mikhail Mar 15 '11 at 15:02
  • @Mikhail: Yes, or I'd assign the result of the condition to a variable. I find it much easier to understand than the logic of break and continue. Abnormally ending a loop just feels weird and I don't like it. – FrustratedWithFormsDesigner Mar 15 '11 at 15:05
  • 1
    Ironically, you've misread my conditions. continue means skip the functionality go to the next loop; not "continue with execution" – Mikhail Mar 15 '11 at 15:19
  • @Mikhail: Ah. I don't use it often and when I read it, I get confused by the meaning. Another reason I don't like it. :P Give me a minute to update... – FrustratedWithFormsDesigner Mar 15 '11 at 15:27
  • 7
    Too much nesting destroys readability. And sometimes, avoiding the break/continue introduces the necessity of inverting your logic on your conditional tests, which can lead to misinterpretation of what your code is doing -- I'm just sayin' – Zeke Hansell Mar 15 '11 at 18:45

No. It's a way to solve a problem, and there are other ways to solve it.

Many current mainstream languages (Java, .NET (C# + VB), PHP, write your own) use "break" and "continue" to skip loops. They both "structured goto (s)" sentences.

Without them:

String myKey = "mars";

int i = 0; bool found = false;
while ((i < MyList.Count) && (not found)) {
  found = (MyList[i].key == myKey);
if (found)
  ShowMessage("Key is " + i.toString());
  ShowMessage("Not found.");

With them:

String myKey = "mars";

for (i = 0; i < MyList.Count; i++) {
  if (MyList[i].key == myKey)
ShowMessage("Key is " + i.toString());

Note that, "break" and "continue" code is shorter, and usually turns "while" sentences into "for" or "foreach" sentences.

Both cases are a matter of coding style. I prefer not to used them, because the verbose style allows me to have more control of the code.

I actually, work in some projects, where it was mandatory to use those sentences.

Some developers may think they are not necesarilly, but hypothetical, if we had to remove them, we have to remove "while" and "do while" ("repeat until", you pascal guys) also ;-)

Conclusion, even if I prefer not to use them, I think its an option, not a bad programming practice.

  • Sorry to be picky, but your second example is missing the output for when the key is not found (so of course it looks that much shorter). – FrustratedWithFormsDesigner Mar 15 '11 at 18:10
  • 2
    not to mention that the first example only works if the key is the last one in the list. – Mikhail Mar 15 '11 at 18:41
  • @FrustratedWithFormsDesigner EXACTLY. I put on purpouse to denote why is preferable that method ;-) – umlcat Mar 15 '11 at 23:09
  • however, you have two routines with different semantics; therefore, they are not logically equivalent. – bit-twiddler Mar 17 '11 at 14:48
  • 2
    your second example has two bugs, one syntactic and one logical. 1. It won't compile because the iterator isn't declared outside the scope of the for loop (therefore isn't available in the string output). 2. Even if the iterator was declared outside of the loop, if the key isn't found in the collection, the string output would print the key of the last item in the list. – Evan Plaice Mar 19 '11 at 7:40

I'm not against continue and break in principle, but I think they are very low-level constructs that very often can be replaced by something even better.

I'm using C# as an example here, consider the case of wanting to iterate over a collection, but we only want the elements that fulfil some predicate, and we don't want to do any more than a maximum of 100 iterations.

for (var i = 0; i < collection.Count; i++)
    if (!Predicate(item)) continue;
    if (i >= 100) break; // at first I used a > here which is a bug. another good thing about the more declarative style!


This looks REASONABLY clean. It's not very hard to understand. I think it would stand to gain a lot from being more declarative though. Compare it to the following:

foreach (var item in collection.Where(Predicate).Take(100))

Maybe the Where and Take calls shouldn't even be in this method. Maybe this filtering should be done BEFORE the collection is passed to this method. Anyway, by moving away from low-level stuff and focusing more on the actual business logic, it becomes more clear what we're ACTUALLY interested in. It becomes easier to separate our code into cohesive modules that adhere more to good design practices and so on.

Low-level stuff will still exist in some parts of the code, but we want to hide this as much as possible, because it takes mental energy that we could be using to reason about the business problems instead.


I will just quote from Code Complete:

Use continue for tests at the top of the loop. A good use of continue is for moving execution past the body of the loop after testing a condition at the top. For example, if the loop reads records, discards records of one kind, and processes records of another kind you could put a test like this at the top of the loop. Using continue in this way lets you avoid an if test that would effectively indent the entire body of the loop. If on the other hand, the continue occurs toward the middle or end of the loop, use and if instead.

| improve this answer | |

Code Complete has a nice section about using goto and multiple returns from routine or loop.

In general it's not bad practice. break or continue tell exactly what happens next. And I agree with this.

Steve McConnell (author of Code Complete) uses almost the same examples as you to show advantages of using various goto statements.

However overuse break or continue could lead to complex and unmaintainable software.

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