Hacker News Reader

Comment by stdbrouw | Hacker News Reader

So you'd also prefer

  if wrapper and header:
    ...
  if wrapper and body:
    ...

  if wrapper:
    if header:
      ...
    if body:
      ...

when coding?

View on HN

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

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

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.

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.

  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.

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:

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

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?

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.

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.

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.

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.

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.

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

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.

Ternary operator to the rescue:

    return something
        ? do_something ()
        : do_something_else();

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.

    if wrapper:
        do_thing_to_wrapper(wrapper)

    def do_thing_to_wrapper(wrapper):
        ...

Reply on news.ycombinator.com