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.

  • UnRelatedBurner@sh.itjust.worksOP
    0·
    11 months ago

    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.

    • crashfrog@lemm.ee
      1·
      11 months ago

      (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 the if predicate is True, and the one where it isn’t.) If there’s two if statements, there’s four paths through the code. If there’s three if 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.

      • UnRelatedBurner@sh.itjust.worksOP
        1·
        11 months ago

        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.

        • simplest I can think of is let’s say we need different logic based on a number’s parity. How do I avoid if x % 2 == 0?
        • crashfrog@lemm.ee
          2·
          11 months ago

          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.