3 ms·

It's nice that they fixed it, but I would always write func hello() int { if cond { return 0 } return 1 } anyway.

pkulak 14y ago
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.
varikin 14y ago
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.
- blablabla123 14y ago
  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.
georgemcbay 14y ago
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.
- nickpresta 14y ago
  I disagree with your use of named returned values for something like that. https://plus.google.com/106356964679457436995/posts/LmnDfgehorU 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.
  - georgemcbay 14y ago
    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.

varikin 14y ago

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.

blablabla123 14y ago
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.

georgemcbay 14y ago

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.

nickpresta 14y ago
I disagree with your use of named returned values for something like that. https://plus.google.com/106356964679457436995/posts/LmnDfgehorU 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.
- georgemcbay 14y ago
  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.