4 ms·

Two If statements, no nesting vs. Three If statements, 1 level deep nesting To me, the first option is clearly simpler and more readable. Then again, lo

by id 11y ago

Two If statements, no nesting vs. Three If statements, 1 level deep nesting To me, the first option is clearly simpler and more readable. Then again, looking at the second option I notice immediately that I can dismiss it if wrapper happens to be false. But it really depends on what the other code lines contain.

obelisk_ 11y ago
I have never really considered repeating conditions instead of nesting. I might try doing so next time since I'm generally not happy with the depth of nesting I sometimes land myself in. The problem I foresee with repeat conditions is that during a change, I might forget to update one or more of the repeat conditions. Also, I wonder, do gcc and/or clang recognize repeat conditions and produce the equivalent of what nested statements would?
- johnmaguire2013 11y ago
  Python taught me some good practices in regards to this. Python's "enforcement" (or rather, strong PEP-8 suggestions) of 80 characters per line teaches you to come up with a lot of ways to avoid nesting. The most useful one, and the one that drives me crazy when I see it, is when people write code like this: if something: value = do something else: value = do something else return value These days I write code like this: if something: return do something return do something else In the simple example, it's not a big deal. But once you have 30 lines of code in between each statement (and nested if statements), it gets trickier to maintain every possible code path in your head. This isn't the same as "show all conditions at once" -- instead it's "ignore the conditions that have already been satisfied." Seeing that we already returned out in condition #1 lets me focus more on condition #2.
  - esaym 11y ago
    Believe it or not, I once interviewed for a cryptography firm and they had me look over some code samples to improve them. Some of my improvements were just what you did. But they stopped me mid way through and said that the "standard" they are required to follow only allows one return statement and it had to be at the end of the function... Don't know what standard it was, whether their own or some 3rd party compliance.
    - johnmaguire2013 11y ago
      I've heard this argument (I like a single exit point) before, but I don't really understand it, I'd love for someone to explain why they prefer it, if they do. I think the main reason returning early works so well is that often times, when you're returning different values, it's because you quickly have an answer (often times that something is invalid) for particular inputs. Generally though, there is "real work" to be done after validating or normalizing your inputs. If that's not true, you're probably trying to do too many things at once, and the different pieces should be broken into separate functions.
      - obelisk_ 11y ago
        In the specific case of crypto, maybe they are concerned about leaking information through timing if they return early? Though even if you have only one exit point, that alone does not in any way guarantee that timing differences won't occur. For that, I think the same work must be done always and only at the very end it is decided whether or not the result is valid. Something like that. So maybe they have some other reason. Maybe it's just cargo cult programming.
  - thaumasiotes 11y ago
    > Python's "enforcement" (or rather, strong PEP-8 suggestions) of 80 characters per line teaches you to come up with a lot of ways to avoid nesting. > The most useful one, and the one that drives me crazy when I see it, is when people write code like this: But... your example doesn't show any ways to avoid nesting. There's just as much nesting after as before. Your change makes the code less tall, which is a problem I've had with Python, but it has nothing to do with nesting at all. I'm actually fond of a third approach: if something: return do something else: return do something else I like the ocaml-style philosophy that it's an error if your condition check isn't capable of handling all possible conditions.
    - oneeyedpigeon 11y ago
      Ternary operator to the rescue: return something ? do_something () : do_something_else();
    - johnmaguire2013 11y ago
      I figured readers could fill in the relevant blanks. Updated example: if something: value = do something else: if something_else: value = do something else else: value = do a third thing As I said in my initial post, "it helps once you have nested ifs, and multiple lines of code." Here's the change: if something: return do something if something_else: return do something else return do a third thing Again, what I'm stressing here is that if you already have your result, you can return, and it makes the code easier to follow than adding a superfluous "else:" statement.
  - obelisk_ 11y ago
    Even worse yet is when people do if some_function(arg, arg2): result = True else: result = False return result Obviously a waste of time and lines of code. Instead, do return some_function(arg, arg2) Unless anything else needs to be done with the result of some_function but that's not the case I'm talking about, I'm talking about when it looks like above.
mc808 11y ago
You could also say that's 4 comparisons vs. 2 comparisons. Not the end of the world, but what if you have one additional level of nesting? if a: if b: if c: if d: if e: if f: if g: Vs. if a and b and c: if a and b and d: if a and e and f: if a and e and g: Or would you perhaps find if a and b and c: if d and b and a: if e and a and f: if g and e and a: Or if e and f and a: if c and b and a: if g and a and e: if d and a and b: In any case, now you have 12 comparisons vs. 3 comparisons. (Though this is not entirely comparable to CSS, since selector order is somewhat more restricted.)

by id 11y ago

obelisk_ 11y ago

I have never really considered repeating conditions instead of nesting. I might try doing so next time since I'm generally not happy with the depth of nesting I sometimes land myself in. The problem I foresee with repeat conditions is that during a change, I might forget to update one or more of the repeat conditions. Also, I wonder, do gcc and/or clang recognize repeat conditions and produce the equivalent of what nested statements would?

johnmaguire2013 11y ago
Python taught me some good practices in regards to this. Python's "enforcement" (or rather, strong PEP-8 suggestions) of 80 characters per line teaches you to come up with a lot of ways to avoid nesting. The most useful one, and the one that drives me crazy when I see it, is when people write code like this: if something: value = do something else: value = do something else return value These days I write code like this: if something: return do something return do something else In the simple example, it's not a big deal. But once you have 30 lines of code in between each statement (and nested if statements), it gets trickier to maintain every possible code path in your head. This isn't the same as "show all conditions at once" -- instead it's "ignore the conditions that have already been satisfied." Seeing that we already returned out in condition #1 lets me focus more on condition #2.
- esaym 11y ago
  Believe it or not, I once interviewed for a cryptography firm and they had me look over some code samples to improve them. Some of my improvements were just what you did. But they stopped me mid way through and said that the "standard" they are required to follow only allows one return statement and it had to be at the end of the function... Don't know what standard it was, whether their own or some 3rd party compliance.
  - johnmaguire2013 11y ago
    I've heard this argument (I like a single exit point) before, but I don't really understand it, I'd love for someone to explain why they prefer it, if they do. I think the main reason returning early works so well is that often times, when you're returning different values, it's because you quickly have an answer (often times that something is invalid) for particular inputs. Generally though, there is "real work" to be done after validating or normalizing your inputs. If that's not true, you're probably trying to do too many things at once, and the different pieces should be broken into separate functions.
    - obelisk_ 11y ago
      In the specific case of crypto, maybe they are concerned about leaking information through timing if they return early? Though even if you have only one exit point, that alone does not in any way guarantee that timing differences won't occur. For that, I think the same work must be done always and only at the very end it is decided whether or not the result is valid. Something like that. So maybe they have some other reason. Maybe it's just cargo cult programming.
- thaumasiotes 11y ago
  > Python's "enforcement" (or rather, strong PEP-8 suggestions) of 80 characters per line teaches you to come up with a lot of ways to avoid nesting. > The most useful one, and the one that drives me crazy when I see it, is when people write code like this: But... your example doesn't show any ways to avoid nesting. There's just as much nesting after as before. Your change makes the code less tall, which is a problem I've had with Python, but it has nothing to do with nesting at all. I'm actually fond of a third approach: if something: return do something else: return do something else I like the ocaml-style philosophy that it's an error if your condition check isn't capable of handling all possible conditions.
  - oneeyedpigeon 11y ago
    Ternary operator to the rescue: return something ? do_something () : do_something_else();
  - johnmaguire2013 11y ago
    I figured readers could fill in the relevant blanks. Updated example: if something: value = do something else: if something_else: value = do something else else: value = do a third thing As I said in my initial post, "it helps once you have nested ifs, and multiple lines of code." Here's the change: if something: return do something if something_else: return do something else return do a third thing Again, what I'm stressing here is that if you already have your result, you can return, and it makes the code easier to follow than adding a superfluous "else:" statement.
- obelisk_ 11y ago
  Even worse yet is when people do if some_function(arg, arg2): result = True else: result = False return result Obviously a waste of time and lines of code. Instead, do return some_function(arg, arg2) Unless anything else needs to be done with the result of some_function but that's not the case I'm talking about, I'm talking about when it looks like above.

mc808 11y ago

You could also say that's 4 comparisons vs. 2 comparisons. Not the end of the world, but what if you have one additional level of nesting? if a: if b: if c: if d: if e: if f: if g: Vs. if a and b and c: if a and b and d: if a and e and f: if a and e and g: Or would you perhaps find if a and b and c: if d and b and a: if e and a and f: if g and e and a: Or if e and f and a: if c and b and a: if g and a and e: if d and a and b: In any case, now you have 12 comparisons vs. 3 comparisons. (Though this is not entirely comparable to CSS, since selector order is somewhat more restricted.)