from Hacker News

Ask HN: Do you follow the positive or negative pattern when programming?

by vpaulus on 5/11/23, 5:01 AM with 5 comments

Me and my coworker follow a totally different pattern while programming. Probably there are a better technical term for that, but I call it now positive pattern and negative pattern.

I prefer the following way (in controllers, etc.):

  function ($param)
  {
    if ($param is not valid) {
      return false
    }

    // do the stuff

    return true;
  }

While my coworker does the opposite:

  function ($param)
  {
    if ($param is valid) {
      // do the stuff

      return true;
    }

    return false
  }

We agreed that none of them is good or wrong, just different approach. I am curious, how do you do, what are your thoughts, pros and cons?

by armchairhacker on 5/11/23, 6:20 AM

In personal projects I do whatever has the code outside of the `if` block longer. e.g.

    function login() {
      if (isLoggedIn) {
        return
      }
      if (!isAuthenticated) {
        throw AuthenticationFailure
      }
      // Do the login
      ...
    }

It doesn't matter that `isLoggedIn` is positive and `isAuthenticated` is negative, the point is both of those are short-circuit cases.

Though what usually actually ends up happening is

    function login() {
      if (isLoggedIn) {
        return
      } else if (isAuthenticated) {
        doTheLogin()
      } else {
        throw AuthenticationFailure
      }
    }
    

    function doTheLogin() {
      ...
    }

Where there's no "long case", so the order really doesn't matter and I just make everything positive.

by proc0 on 5/11/23, 6:10 AM
Personally, I think they're both sub-optimal because it's not abstracting the arg. check all the way. I think code is easier to reason about if your functions return one data type... and although the examples are returning boolean, in most cases functions return "stuff", and applying that to the examples would make their type "stuff | boolean". As the codebase scales this can be a source of pain for adding new things or finding bugs. The solution is abstracting the param check, and then composing two functions, one function that checks params, followed by the function that modifies "stuff". That way not only is the logic reused cleanly, but the functions will always return "stuff". This has drawbacks of course, as abstracting too much can become unwieldy, however I think there is a lot of power that comes along with it.
by throwaway_5753 on 5/11/23, 5:19 AM
Two things I think about (obviously it's very context dependent):
- Quick returns go inside the condition to save a level of nesting in the function; try to minimize level of nesting of the main function body
- I try to return a value at the end of a function that will do the least harm if I somehow fall through (because maybe I've messed up the condition or something), for example:
```
    def launch_nukes():
        if you_are_sure():
            launch()
        abort()
```
It's not always obvious how best to structure a function to meet the second criteria, but in general I try to think defensively (how to minimize chances of bad bugs both now and when I come back in 6 months).
by deofoo on 5/11/23, 7:08 AM
Negative, this keeps things consistent and clean. Here's a great article https://szymonkrajewski.pl/why-should-you-return-early/
by prudentpomelo on 5/11/23, 6:36 AM
I prefer early returns. It avoids nesting when checking preconditions. However, the function must always return the same type.