Software Engineering Stack Exchange is a question and answer site for professionals, academics, and students working within the systems development life cycle. It only takes a minute to sign up.
Sign up to join this community
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?
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:
goto.goto to the branch target.
(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:
break (or continue, depending on the task).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.
break or continue. Several implementations added them, but they were never part of the design of the language.
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.
