When it comes to programming you’ll find there’s rarely a right and wrong, it’s usually a question of “meets requirements” or not. She’s your customer and she says not to use breaks or it doesn’t meet the spec (be thankful that customers in the business world are rarely this specific).

She’s reasoning is that it makes the code harder [for her] to read, and breaks the flow of it or something. (I didn’t get her yapping tbh)

Fixed it for you. She’s imposing her preferences on the class. Unfortunately, it’s easiest to just suck it up and appease her than to fight it. Just my two cents.

Assuming C/C++, dare we even ask what this teacher uses instead of switch statements? Or are her switch statements unreadable rat’s nests of extra conditions?

This is a good life lesson. We’re all idiots about certain things. Your teacher, me, and even you. It’s even possible to be a recognized expert in a field yet still be an idiot about some particular thing in that field.

Just because some people use a screwdriver as a hammer and risk injuring themselves and damaging their work, that’s not a good reason to insist that no-one should ever use a screwdriver under any circumstances, is it?

Use break statements when they’re appropriate. Don’t use them when they’re not. Learn the difference from code that many other people recommend, like popular open-source libraries and tutorials. If there’s a preponderance of break statements in your code, you may be using a suboptimal approach.

But unfortunately, for this course, your best bet is to nod, smile, and not use any break statements. Look at it as a personal learning experience; by forcing yourself sit down and reason out how you can do something without using break statements, you might find some situations where they weren’t actually the best solution. And when you can honestly look back and say that the solution with break statements is objectively better, you’ll be able to use that approach with greater confidence in the future.

There will always be some instructors that are more dogmatic than pragmatic. All the same, there will be instructors that have pearls of wisdom to offer. Regarding the “break” and “continue” keywords, this lays somewhere in the middle.

One of the purposes of higher-level programming language is to remove from the low-level, machine-specific language of assembly, by offering other, more descriptive constructs, like “while”, “for”, and “switch”. In the C language, “break” is almost mandatory in a “switch” statement but only occasionally shows up in a “for” loop, excepting drivers. In Python, “break” only exists in loops, but there are lots of loops which can be replaced more efficiently with comprehensions, so “break” can be a sign of poorly organized logic.

If you can specify which programming language you’re learning, it would help to understand what your instructor might have meant to teach.

There is a school of thought that break and continue are just goto in disguise. It helps that these two are more limited in scope than goto and can be considered less evil. If you read the book Clean Code by Robert Martin (it should be required reading for all developers), you’ll see that he doesn’t like functions to be very long. I think his rule is no more than 4 lines. I try to keep mine around 10 or less with a hard stop at 20 unless it can’t be avoided because I’m switching over a large enum or something. If you put your loops into functions then you can just use return instead of break.

I did have a discussion with a teacher once about my use of early returns. This was when I had returned to school after many years as a professional programmer. I pointed out that my code has far less indentation than theirs and was simpler because of it and that it is common in the world outside of education. I got all of my points back he has deducted.

You’re going to hear some good and bad advice from your teachers. Once you have a job check out what the good developers are doing and just follow them.

Well, sometimes it is possible to write a loop with break or without it, and in such cases solution without break is better readable. But if you don’t see a simple way to avoid using break, use it. It is very common, as well as having multiple return statements in function. Even goto can be a good solution sometimes if it points to label located below and not very far.

However you should avoid some antipatterns. If you write an infinite loop that is interrupted only by break, it is highly likely that you are doing something wrong. Nested loops with multiple breaks or gotos are very hard to read and debug. Such code usually can and should be rewritten for better readability and to avoid possible errors (occasional hangs, for instance).

Okay, I want to clarify two different but highly similar syntaxes: break; and break 3;. The latter syntax of break #number is fucking awful and you should never use it. In most languages it’ll only count loops and not conditionals so it can be extremely hard to tell how many levels of indentation you’re unrolling and it’s probably a code smell about having an overly complex function anyway.

However, good old single level break and continue are awesome and useful for making it really clear what preconditions exist in complex situations when looping. It’s much easier to read a series of elementary if break statements than one single gigantic if statement with half a dozen conditions.

Most tools in our toolbox are useful… oh, except goto (unless you’re programming in assembly language). Fuck goto.

When I need a break I make use of a break

A blanket rule against certain keywords sounds pretty silly to me. Break and continue are useful tools in the right situation. Sounds like it’s her preference that she’s decided to impose on the rest of you.

You could ask her what she expects as an alternative. You could show her code that uses it and ask how she expects you to rewrite it to satisfy her standards. Ask nicely because unfortunately just being right isn’t enough for some teachers, they have to like you too.

If she has a good answer, then do it that way as long as you’re in her class. If not well… sorry that’s just a terrible teacher.

This is too unspecific, not a focused question. Yes, break and continue break directed program flow. Like early returns do too. That doesn’t make them bad tools though. Use them where they make sense.

The only time I’ve used break outside of switch statements is to break out of for each loops early, when I’m checking to see if at least one element in a collection meets a condition. I really don’t think there’s ever a good time to use continue, to be honest. And if you use a labeled break statement, that’s a problem.

Well if you can’t break out of anything then I guess you will just have to return instead. I’m sure this will result in code that is much easier to read.

I suspect “you’ll fail the test if you use break” is more of a joke by your teacher than an actual grading rubric, although if you used it more than twice in the same test I wouldn’t award you better than a B.

Is there a benefit to not using breaks or continues?

The benefit is that you learn to write non-branching code. That’s important for beginners, who tend to write very complicated and complex code with lots of branching, which they then discover they’re not able to test and debug. Barring you from using break and continue forces you to write more abstract code to achieve the same level of function with less complexity, and that’s how programmers advance in skill - simpler, more abstract code.

Ultimately it’s an effort to kick a crutch out from under you. Whether you think that’s appropriate for a teacher is up to you, I guess - I’m inclined to think it is, but many students don’t respond well to being challenged.

deleted by creator