4 ms·

So you'd also prefer if wrapper and header: ... if wrapper and body: ... to if wrapper: if header: ... if body: ... when c

So you'd also prefer if wrapper and header: ... if wrapper and body: ... to if wrapper: if header: ... if body: ... when coding?

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.
- 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.)
teej 11y ago
To be totally honest? Yes. Co-locating all the conditions makes it easier to comprehend at a glance. There are obvious drawbacks, but I lean toward this style more and more. Consider the case below. If I want to understand what conditions are necessary for body, that code is now offscreen. I generally consider overly-nested conditions as code smell. if wrapper: ... 30 LOC ... if header: ... 30 LOC ... if body: ... 30 LOC ...
- al2o3cr 11y ago
  "... 30 LOC ..." followed by three or four more in the same logical chunk seems like the smell you should be worried about if fitting everything on one screen is the concern.
  - nine_k 11y ago
    It's not about fitting things onto screen; it's about fitting things in brain. If ~25 years of doing programming for money taught me something, it's that the code is written to be read and maintained by humans, and having really short, clean, one-purpose, composable functions makes your life easier both long-term and short-term.
    - Moru 11y ago
      Amen to that, friend :-) First thing on programming class in the eighties-nineties: "Fit all functions on one screen." At that time that was roughly 22 lines depending on editor used.
pcurve 11y ago
Yes. It's easier to troubleshoot CSS when pre-compiled/processed code looks similar to post-compiled/processed code. Also, it does force you to write CSS more efficiently because if you work with pre-processor language, you often don't see the bloat.
Hello71 11y ago
if wrapper: do_thing_to_wrapper(wrapper) def do_thing_to_wrapper(wrapper): ...

So you'd also prefer if wrapper and header: ... if wrapper and body: ... to if wrapper: if header: ... if body: ... when coding?

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.
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.)

teej 11y ago

To be totally honest? Yes. Co-locating all the conditions makes it easier to comprehend at a glance. There are obvious drawbacks, but I lean toward this style more and more. Consider the case below. If I want to understand what conditions are necessary for body, that code is now offscreen. I generally consider overly-nested conditions as code smell. if wrapper: ... 30 LOC ... if header: ... 30 LOC ... if body: ... 30 LOC ...

al2o3cr 11y ago
"... 30 LOC ..." followed by three or four more in the same logical chunk seems like the smell you should be worried about if fitting everything on one screen is the concern.
- nine_k 11y ago
  It's not about fitting things onto screen; it's about fitting things in brain. If ~25 years of doing programming for money taught me something, it's that the code is written to be read and maintained by humans, and having really short, clean, one-purpose, composable functions makes your life easier both long-term and short-term.
  - Moru 11y ago
    Amen to that, friend :-) First thing on programming class in the eighties-nineties: "Fit all functions on one screen." At that time that was roughly 22 lines depending on editor used.

pcurve 11y ago

Yes. It's easier to troubleshoot CSS when pre-compiled/processed code looks similar to post-compiled/processed code. Also, it does force you to write CSS more efficiently because if you work with pre-processor language, you often don't see the bloat.

Hello71 11y ago

if wrapper: do_thing_to_wrapper(wrapper) def do_thing_to_wrapper(wrapper): ...