Why does my CS professor say that break, goto and continue statements are bad style, Sup Forums?

Why does my CS professor say that break, goto and continue statements are bad style, Sup Forums?

Because academia is full of mental-masturbators who have never worked irl projects where your (((boss))) wants everything done by the weekend...

Well for one, goto is a great way to create marvelously unreadable code. Try it. Use it a bunch on a big project, forget about it for a week and then come back. Try and read your code. You'll be lost

This. Goto sucks

>break
Good in C programs, bad in business or phone software where exceptions are king and if-else statements are not used for imperative/functional reasons.

>goto
Literally gotos a specific line of code. You're not on ASM, don't do this.

>continue statements
Same as why break is bad.

Break and continue aren't bad unless they're abused.

>gotos a specific line of code
C doesn't work like this.

Because he's not a programmer.
Academia is where you go when you can't make it in the professional world.
Like they say, if you can't do, you teach.

>break and continue are bad style
I understand goto but I don't know what's so bad about break or continue.

Goto should be obvious. It's hard to read, and there's just no reason to use it over some if statements or break statements.

Break is fine in most projects, but really only for small only-can-occur-here type of unexpected behaviors where it's just unnecessary to make a new exception and try/catch statement just for this, especially when it's something minor. It's not fine when you're dealing with actual errors or major problems; those should get fixed, not avoided.

Continue is fine for if something was already "handled" and you don't want it to "handle" it again. I mean, it could be avoided by using a huge if statement, but it is more readable to put one if statement and a continue statement inside a large loop block. Continue isn't fine when you have some extra "if this also needs to be done" type of thing, as that could just be put in another method and be handled with an if statement.

Goes to a specific function, my bad dawg.

It's called a label. A function is completely different new friend.

You should ignore anyone who tells you not to use break or continue, as there's not really a better way around them. They're perfectly fine constructs, and break is outright mandatory in C if you use switch statements. Most uses of goto are better accomplished with proper control flow, however, and abuse of goto can lead to the some pretty ugly spaghetti code. Regardless, there are at least two good uses of goto that warrant their continued existence in the C programming language. The first is escaping out of a nested loop, and the second is for dealing with error recovery, where one or more objects may need to be de-allocated, closed, etc... It may make sense to put some cleanup code at the end of the function, that you can just jump to instead of cleaning up and returning in some if statement every single time you come into an error.

He is too busy being a cucked professor instead of making $200k in industry. He likely has no idea what he's talking about. The industry and its standards changes so quickly that something he thought would be static is now gone and forgotten.

kill yourself

They lie to you. Jews hate efficient code.

while True:
if condition:
break
What's wrong with this?

Creating a bunch of retarded objects is also bad though, doesn't mean oop is total garbage. Goto is fine for a few things like parsers and error code returning/cleanup.

Your fucking retarded dude not even asm works like that

Pretty much, it's good when it's the best way to solve a problem. But it's bad when it's used to solve problems that have more elegant solutions. Just so happens it's usually easier to do something the wrong way and have it blow up in your face later.

Agreed but there's something weird where academia made this cargo cult around "goto considered harmful", and remove the context to just mean goto it's bad full stop -- it's not.
And it's weirder that goto is basically this gigantic boogey man while other complicated shit, students have no business doing, gets a pass

>break
>continue
>bad
anyway goto isn't bad either if you only use it in C for early returns with resource cleanup

because you can just do while not condition: brainlet

As long as it doesn't make your code unreadable and unmaintainable it's fine.

please don't respond to bait

while !a || !b || !c || !d || !e || !f

I don't know if you're trying to make a point with this but that is retarded as fuck.

>that is retarded as fuck.
that's the point i was making

That's horrible design, the only point you made is that you are incapable of critical thought.

stay retarded I don't care

Code flow should be easily transferable to a functional style. You can't use continue or break in LISP

Don't listen to this bullshit.
Bosses who want everything done yesterday for half the price are the reason we have shitty software that is impossible to use or maintain.
You have a responsibility as a software craftman to refuse to cut corners.
Would a surgeon agree to stop washing his hands before performing because management told him to?

LMFAO not a single fucktwat here gets it. No wonder since we are on the board that considers Rust and functional programming to be the pinacle of software engineering.

Break, continue, goto and midway returns are discouraged only when you need to formally prove your algorithm with Hoare calculus, but it is all the better when you actually implement your crap on the machine. Break, continue and goto are mere jumps in assembly (return is similar). They are perfect for performance and not that unreadable (goto is fine for putting all your cleanup code at the end of a function).

>goto and continue statements are bad style
Because they've never written a line of practical code in their life.

The real skill is to know when a goto statement is absolutely NECESSARY.

what if the condition is not available at the outer level of the while statement?

Using a boolean variable.

why would you expose an otherwise useless variable to the top level?
that is just bad design

Not him, but it's actually good and ideal design, not to mention more readable.

if A && B && C implies a condition isGood to be true, it is far more readable to create a top level (top in relation to the loop) member for readability and possible continued use.

isGood = False
while not isGood:

is much better than relying on breaks especially if you have multiple statements that go into determining the boolean value of isGood, because in a week or two looking back on all those breaks will make you wonder what you were thinking, let alone if you are working with somebody else.

Obviously in the case the other guy presented with A || B || C it would change corespondingly, but you get the idea.

because you morons aren't able to discriminate between good uses and bad uses yet, so he has to give you a blanket statement, so that you don't shoot yourselves in the foot

Pretty much this

Pretty much this

What is a good way to implement finite state machines without gotos?

>Why does my CS professor say

Maybe (you) might ask him?

Here's some magic.
if condition //isGood == true