I once asked that question to a friend whom is currently employed at microsoft (at was at the time employed in the team working on Project Volta, now known as “Reactive Extensions”), because at university my lecturers used to say that “breaks are bad”. He had a chuckle and said it was probably a lecturer whom never wrote industry code.

Seeing as they use breaks in code, I don’t see why writing it in an interview would reflect badly, as long as you understand the advantages and/or disadvantages in the scenario they asked you to work out.

Being able to know why you opted for one or the other will show insight, which is important. Imagine your insight in the problem and general solution was great, but you used a break, that’s easy to fix. They just tell you not to use breaks anymore. On the other hand, if you didn’t use breaks, but the algorithm was otherwise sloppy, that’ll be worse for your odds.

It’ll depend on the problem at hand as well though, and like World engineer wrote as a comment, on a lot of other variables as well.

Along with use of semicolons in Javascript, whether to use vi or emacs in the Unix world and whether to use a single return statement in a function it’s a controversy that often doesn’t make sense to most production coders. If it makes sense to use it and the code remains clear, then I think you’ll be fine. If not, then don’t use it.

Now knowing the arguments for and against using break is probably more useful if it gets brought up in an interview.

This is my advice, and it has nothing to do with whether using break is good or bad: Code the way you code. They want to know how you code, not how you think they code.

You may be thinking that it’s best to outsmart the interviewer by telling them what they want to hear. In a worst case scenario they’ll hire you, and then you’ll look like an idiot because you gave a wrong impression and don’t write the same type of code they expected, and they’ll fire you a few miserable months later for failing to live up to their expectations.

Be honest in an interview. If they don’t hire you because of your coding style, that’s a win all the way around. They don’t get someone that doesn’t fit with the way they work, and you don’t get stuck in a job where you have to write code in a way that is unfamiliar to you, where you’re ridiculed for your coding style, and where you’re constantly worried they will find out you’re not who you pretended to be during the interview.

That, and be prepared to explain why you used break, and why you think that was the right or wrong choice. As an interviewer, I don’t care so much about what the candidates say or write on the whiteboard, as long as they can give me a rational explanation for their choice.

This question is at risk of being a duplicate of Are `break` and `continue` bad programming practices? but I will try to give a more theoretical explanation.

I forgot the reference but I would appreciate if someone can find it and I will be happy to include it here, or you can edit into my answer without asking if you have the reps.

The theoretical explanation was originally given to support some limited use of goto, and the justification to these limited usage later gave rise to the structured control flow statements we’re familiar today.

The justification is this. Perform the following exercise on paper:

• For the purpose of this exercise, treat all control transfers (both unconditional and conditional) as goto.
• List the program code for a single function. If you would like to analyze more than one function, inline it into the top-level function.
• Draw arrows to connect each goto to the branch target.
  • Put all backward- (upward-) going branch arrows on the left of the program listing.
  • Put all forward- (downward-) going branch arrows on the right of the program listing.
• If you can figure out a way to arrange those arrows without any two crisscross each other, your code is said to have a sensible control transfer structure.

(The terminology used here may have diverged from the original reference.)

Now let’s examine the two keywords being questioned: break and continue.

I assume that your are referring to their use inside loops. As others point out, break is mandatory in switch statements (or at least your future employer’s coding standards would have made that mandatory), so there is no point in arguing.

• break is simply a control transfer to the bottom (exit) of the loop. Therefore it does not crisscross the control flow of the loop itself.
• continue transfers to the top (loop advance and condition test) of the loop. If the condition test is false it also exits the loop. Note that the “if condition test fails …” part is a different control flow. continue only needs to transfer to the top.

Simply put, break and continue used inside a loop doesn’t violate the sensible control flow structure. This is why they are allowed in the first place in historically significant languages such as Pascal, etc where language design trumps practical considerations.

Now, regarding some posts saying that break is bad if it appears in the middle of some non-side-effect-free code – I would say yes and no.

Most of the time, if you see this happening, it is because it has to be so. The reality makes this argument moot.

Example: in some of your code, you have to do this inside a loop:

• Check condition A first. If it fails you can do break (or continue, depending on the task).
• Only if condition A is satisfied, you can start computing some value B.
• With B computed, you will also check condition B (using the value of B).

Can you move the condition check B to the top of the loop? You can’t. It’s dictated by the nature of the task you are implementing. Thus the argument is moot. If at all, that argument favors decomposing long functions into shorter subroutines, rather than arguing for careful positioning of the use of break statements.

Personally, I would frown upon break outside of switch statements. But that said, I would frown more if the code was wrong. If break is what you’re used to and you can produce functional code with it, go nuts. It shouldn’t disqualify you from any job.

It’s hard enough to find competent programmers. Competent programmers that code in my preferred style are more like unicorns.