Is inserting a break statement anywhere but in a switch statement a horrible idea and results almost always in bad code? Why? My lecture notes say so. lol.

e.g.:
loop(someJsonDataSet){
if(company.getName().equals("xyz")){
break; // don't process records of this
company
}
}

Well, if there are other companies that needs to be checked, you won't even get to them if you use `break`. A `continue` statement should do the trick.

Assuming you're using something Java-like

@swagnette Oh, indeed. : )

@swagnette Using Java in this case.

-

Or well, now I didn't use .equals() like Java does, but you probably get the point

@swagnette Yes I do. Thanks for the code. : )

BS, sometimes you want to break a loop after finding a result in it. You can use a break if you want.

Most of the time there might be a functional equivalent to what you're doing, but a good ol' break is Sometimes easier to read and maintain anyway

@Hazarth It certainly is - I remember the Pascal's "clean code" crap where you ended up introducing some additional flag in the loop control statement just to work around the missing loop break.

@Hazarth https://softwareengineering.stackexchange.com/... Here, under the section "A comment on why break/continue are "more smelly" than return.
" one argues about the smell of having to maintain state in your mind.

@CaptainRant It's a good argument, albeit I'd argue it's not universal.

for example you might want to do some "clean-up" after the loop before you return... if you used return, the clean-up code would need to be part of the IF block that contains the return... mixing concerns... which is also a code smell or perhaps instead of clean-up

and honestly, sometimes it's simply not worth it extracting a loop into it's own method, or the loop is extremely dependent on state already and you would need to pass around tons of variables or introducing a new carrier object just to do that... a loop could be so intertwined with your current method that keeping the state in your mind is something you would already have to be doing.

I mean It's easy to hypothetically only imagine clean and beautiful code that you have full access too.. but in reality a loop break is a great asset

Your flow control statements form a network, you can think of this like a rail network around a city. Several entry points, collectors and exit points. The more complicated your network, the harder it gets to account for every train going in all directions. Break, continue, early returns and goto introduce slip lanes, which can result in very confusing journeys that skip stations you thought unskippable. These aren't forbidden tools, in a simple enough function even goto might be sensible, but they have to be used in moderation and you have to make sure that their presence is apparent to anyone reading any code that they might affect.

I'd prefer generators or functions (with return).

As long as the loop itself is not nested, it's okay.

Nested loops or even worse an complete bukkake of loops and control Statements which contains breaks or continues is indeed messy and smelly.

Especially when things like break <N> exist and you can skip from an inner nested loop to an outer loop.

Eg.

while(moo > 3)
foreach(...)
for (...)
if bla
continue
...
if joker
break 2

Good luck figuring out the control flow. I've debugged and refactored a lot of times such messy shit and it never ended well on the first attempt.

:-(

@lbfalvy A good analogy, thank you.