this post was submitted on 29 Nov 2023
-7 points (34.8% liked)
Programming
17326 readers
150 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
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.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
andcontinue
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.
well, It's not a joke. But the rest is way to optimistic. You aren't the first to say that my teacher is just way smarter.then I give credit for but the thing is, noone (in my class) that I tried to share this idea with believed this to be the case. I'll stay optimistic, and see what'll happen.
Thanks for the warning about overly braching code, I'll keep that in mind. (however, I don't get why more loops and ifs makes a function harder to test, I'm just going to trust you and that I'll find out later.
Well, it's fairly easy to explain - each branching statement in your function doubles the number of discrete paths through the code. If there's one
if
statement, there's two paths through the code. (The one where theif
predicate is True, and the one where it isn't.) If there's twoif
statements, there's four paths through the code. If there's threeif
statements, there's eight paths through the code.In order to test a function completely, you have to test every possible path through the code. If you used three
if
statements, that means you have to devise and write eight tests just for the different code paths, plus testing various exceptional cases of the function's input ("what if all inputs are 0", "what if all inputs are null", "what if the integer is a string", etc.) That's a lot of tests! You might even have to write tests for exceptional cases combined with different code paths, so now you're writing eight times the number of tests you otherwise would have had to.Whereas if your function doesn't branch at all, there's only one path through the code to have to test. That's a lot fewer tests which means you'll probably actually write them instead of saying "well, it looks like it works, I won't spend the time on tests right now." Which is how bugs make it all the way through to the end of the project.
Thanks, it makes sense. I just don't yet see how I'd reduce the number of ifs*, but I guess it's a case by case thing.
if x % 2 == 0
?What would be an example where you need different logic based on a number's parity? Why wouldn't you write logic that ignores the number's parity?
Part of getting better as a programmer is realizing which stuff doesn't matter, and writing less code, as a result.
oh, okay, I hear you. Thanks
Good luck