I have an upcoming internship interview with Microsoft and, although I rarely use break in my own code, it does simplify things a lot of times and bring me to a solution faster when coding on the whiteboard.

To anyone familiar with the interview process, would it reflect badly on my coding style? I'm not asking about whether breaks are bad or not in general, but should I try to go for Boolean checks instead during the interview?

  • Depends on the company and the language and the problem and the...(insert other variable here) – World Engineer Nov 30 '14 at 2:04
  • I'm assuming the language is C/C++/C# - just pointing out the obvious that break is necessary in switch clauses. – tbsdy Nov 30 '14 at 2:49
  • Microsoft interviews are notoriously tricky beasts, mine was a whole day (8.30-5.00) and they are not like any other interview process I've ever seen. Agonising over use of a keyword in a coding interview is a good sign you might be out of the running before you step into the building. The advice in the answers so far is sound, I'd just add to read, learn and inwardly digest the book writing secure code and to study the patterns and practices. As for 'break', even 'goto' - use it if that's the clearest way to state your intent. – James Snell Nov 30 '14 at 10:34

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.

  • 1
    Use of semicolon in JS is not just a matter of preference, incorrectly omitting them can cause your program be incorrect. inimino.org/~inimino/blog/javascript_semicolons – Andy Nov 30 '14 at 22:00
  • 1
    My point illustrated perfectly. – tbsdy Dec 2 '14 at 0:00
  • Use of VI or emacs is a preference which in the end doesn't impact program behavior, likewise for single return or not; JS' SCI in fact does lead to changes in program behavior which surprise many (the return without a ; follow by the return value, which doesn't do what many expect). Lumping in the JS SCI is extremely misleading in you answer, and bringing it up in the context of other personal preference choices does NOT illustrate your point. – Andy Dec 2 '14 at 15:04
  • Actually, use of break/no break is indeed a personal preference. It matters very little if you use it/don't use it so long as you know why you should use it. If you misuse break then that affects your program behaviour. I love those who are willing to argue about JS semicolon behaviour, btw. They get red in the face, it's quite amusing. Especially when they miss the main thrust of the argument, and don't provide their own reasoning (possibly because they don't have anything to contribute) :-) – tbsdy Jan 9 '15 at 19:40

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.

  • No historically-significant version of Pascal (Niklaus Wirth's 1973 final report, ISO 7185 or ISO 10206) had break or continue. Several implementations added them, but they were never part of the design of the language. – Blrfl Nov 30 '14 at 14:40
  • I like the "do the lines criss-cross" notion, though placement of arrows on the right or left would need to be more flexible. Otherwise even something as simple as "if/else if/else" would be unworkable since there are a forward transfers from the first "else if" to the "else"'s block, and from the end of the "else if"'s block to the code following the "else"'s block. – supercat Nov 9 '17 at 18:06

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.

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