7 ms·
They finally fix: func hello() int { if true { return 0 } else { return 1 } } >go run func.go ./func.go:3: funct
by schoper 13y ago
They finally fix:
func hello() int {
if true {
return 0
} else {
return 1
}
}
>go run func.go
./func.go:3: function ends without a return statement
- mahmoudhossam 13y agoAlso not handling JSON null values: https://code.google.com/p/go/issues/detail?id=2540 https://code.google.com/p/go/issues/detail?id=2540
- voidlogic 13y agoI'm pretty sure that was fixed in both previous betas and tip for some time before that.
- mseepgood 13y agoIt's nice that they fixed it, but I would always write func hello() int { if cond { return 0 } return 1 } anyway.
- pkulak 13y agoBack 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 13y agoThe 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 13y agoWhen 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 13y agoIn 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 13y agoI 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 13y agoYeah, 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.
- chatmasta 13y agoI've been taught by some pretty experienced engineers that in terms of readability, multiple return statements are a bad idea. Instead, you should conditionally set a return variable, and return it once at the end of the function. But I'm not sold.... what is HN's thought on this matter?
- jbooth 13y agoWith go's defer mechanic (defer f.Close(), defer l.Unlock()), and the way they handle errors, multiple returns are basically the way code comes out naturally. I think it's more readable than juggling a bunch more variables and returning at the end, others may disagree.
- ihsw 13y agoUse guard clauses[1]. [1] http://martinfowler.com/refactoring/catalog/replaceNestedConditionalWithGuardClauses.html http://martinfowler.com/refactoring/catalog/replaceNestedCon...
- Jabbles 13y agoGo discourages it http://golang.org/doc/effective_go.html#if http://golang.org/doc/effective_go.html#if I think a blanket ban on multiple return locations is silly, as they can often be used to simplify code. There may be times when setting a return value is preferable, and I think you should use your judgement there. http://stackoverflow.com/questions/36707/should-a-function-have-only-one-return-statement http://stackoverflow.com/questions/36707/should-a-function-h...
- dscrd 13y agoOnly a sith etc etc. Like just about every other blanket statement about programming, this also is sometimes true and sometimes not. I find that multiple return statements in a function are more often a symptom of ugly code instead of the reason.
- genwin 13y agoI used to follow a bunch of best practices like this, that I now often find to be of too little benefit. If the function is small, multiple return statements won't significantly affect readability and it's simpler to code.