Hacker News Reader

Comment by mseepgood | Hacker News Reader

It's nice that they fixed it, but I would always write

    func hello() int {
        if cond {
            return 0
        }
        return 1
    }

anyway.

View on HN

The reason I don't like this way is it can be harder to refactor. You don't want "return 1" happening if cond. For example, if you refactor to something like this:

    func hello() int {
       var result int
       if cond {
          result = 0
       }
       result = 1
       
       // New code with result

       return result
    }

Now, in this case, you don't want result to be 1 if cond, so you have to add the else condition. If you start with if-else, this is less likely to bit you in the future.

This particular bug just bit me in a bad way in production because I had what you have and and to make an quick production fix and did a refactor just like this and missed adding the else.

When you do a lot of I/O you always have err return values included. For that I find the style without else much more convenient.

In languages with ternary I would do this (I agree with Go's decision to remove it but in a case this simple, I'd use it if it were there)

  int hello() {
    return cond ? 0 : 1
  }

In Go, I'd do this, but then I seem to like named return values more than most Go programmers...

  func hello() (res int) {
        if !cond {
            res = 1
        }
        return
    }

Of course, coming from C/C++, it would have to be an extremely special case for me to have logic where "true" mapped to 0 and "false" mapped to 1, because that just seems wacky.

I disagree with your use of named returned values for something like that.

https://plus.google.com/106356964679457436995/posts/LmnDfgeh...

EDIT: Sorry, let me explain (I'm not an asshole, really!). I disagree with using named returned for things outside of signaling error/ok states (as explained by Andrew). I feel that our signatures should be written concisely for users of our API, not for our convenience.

Yeah, as do other other Go programmers I know of, which is why I said "I seem to like named return values more than most Go programmers".

I respect Andrew Gerrand and Brad Fitzpatrick quite a lot but I still often use named returns on even small functions. I find doing so usually makes the actual function code more concise and easily readable for me and I don't think the negative impact on the docs is significant. IMO auto-generated go-docs have far worse problems than the 'noise' from named returns, I think they suffer a lot more from core language decisions like the flexible interface system. And to be clear, I think the interface system in Go is brilliant and I love using it, but I also think it makes auto-generated go-docs hard to digest (and use as quick references) in a way that auto-generated OOP language docs (javadoc, doxygen from C++, etc) aren't.

Back when I was in college doing Java, Eclipse would throw up an error for unnecessary "else" statements. Ever since then I can't help but write it your way as well.

Reply on news.ycombinator.com