I've so often seen break (or continue) improperly used to manage the end condition of for (or while) loops that I came to see it as an immediate hint toward a poorly designed code. I'm not saying there are absolutely no case where it's the correct way to do, but I've seen so many counter examples and I personnally had so few occasions where there was no better way that "breaking loop is bad" became one of my rules of thumb. In this article I want to show a few examples I've encountered at work to illustrate why I came to think that way. Examples below are only edited for shortening and converted to pseudo-code when the language is irrelevant. Except for that they are as I've found them.

flag = true while true if flag is false break (code eventually setting flag to false) end would better be: flag = true while flag is true (code eventually setting flag to false) end files = glob("*.*") for file in files if file not ends with ".jpg" continue (code doing something with file) end would better be files = glob("*.jpg") for file in files (code doing something with file) end while true if time greater than max_time break (do something) would better be while time less or equal than max_time (do something) looking for an id not already used (the actual value of the id was irrelevant): for id in range(...) if id not in (list of used ids) break (code using id) would better be id = max(list of used ids) + 1 (code using id) searching an element in an array using Python's horrendous for-else construct for elem in array if (condition on elem) break else return False return True would better be (and yes, there are surely more "pythonic" way to write it, I just care here about the break) for elem in array if (condition on elem) return True return False creating an array of the first indices fulfilling a condition array = empty array for i in range(...) if (condition on i) add i to array else break return array would better be array = empty array i = 0 while (i < 255) and (condition on i) add i to array increment i return array