this post was submitted on 29 Nov 2023
-6 points (41.2% liked)
Programming
17423 readers
67 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
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 !webdev@programming.dev
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
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.
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.
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.
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.