Programming

17669 readers

174 users here now

Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!

Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.

Hope you enjoy the instance!

Rules

Follow the programming.dev instance rules
Keep content related to programming in some way
If you're posting long videos try to add in some form of tldr for those who don't want to watch videos

Wormhole

Follow the wormhole through a path of communities [email protected]

founded 2 years ago

MODERATORS

snowe

Ategon

[email protected]

-7

Real quick question about the "break" (sh.itjust.works)

submitted 1 year ago by [email protected] to c/programming

65 comments fedilink hide all child comments

I'm studying programming, and I don't agree woth my teacher. She basically said that if we use break (and continue too maybe) our test is an instant fail. She's reasoning is that it makes the code harder to read, and breaks the flow of it or something. (I didn't get her yapping tbh)

I can't understand why break would do anything of the sorts. I asked around and noone agreed with the teacher. So I came here. Is there a benefit to not using breaks or continues? And if you think she's wrong, please explain why, briefly even. We do enough down talking on almost all teachers she doesn't need more online.

you are viewing a single comment's thread
view the rest of the comments

[–] [email protected] 4 points 1 year ago* (last edited 1 year ago) (1 children)

you’ll see that he doesn’t like functions to be very long. I think his rule is no more than 4 lines.

Four line functions? Sounds like a codebase adhering to that rule would end up as a nice thick function soup. It feels like..... I dunno, those database programmers that like normalising databases to the Nth degree.

If you put your loops into functions then you can just use return instead of break.

And that just sounds like abusing the concept of functions to replace standard flow control that your language provides.

I mean, sure, if I find repetitive chunks of code popping up I'll break them out into functions, but - generally speaking - I do functions that translate into discrete real-world or UI tasks. I'm opening and parsing a text file into internal structures, I'm doing the reverse to go back to a data file, I'm cycling through the data to update UI components, etc etc.

But hey, I use C and on the rare occasion I sneak a goto in there, so I'm not qualified to pass too much judgement.

[–] samus7070 2 points 1 year ago

Yeah, it’s a bit on the extreme side for me. 10-20 is what I prefer. I find that if I follow that rule the code is easy to come back to later because the things a function does are more clearly defined. I can look at a higher level function and it’s filled with function calls like readX, createY and doThis. I don’t have to look at as many blocks of code and try to remember what the intent was.