3 ms·

The Go code review document gives a brief comment about when they like and don't like to use them[1]. Personally the only time I find them to be acceptable is

by cyphar 9y ago

The Go code review document gives a brief comment about when they like and don't like to use them[1]. Personally the only time I find them to be acceptable is when you have to reference a returned value in a defer. All other usages are questionable, though this is a taste thing and is likely because of my dislike in it's usage as a way of omitting a `var` in a function body (and also the fact that naked returns are magical in comparison). [1]: https://github.com/golang/go/wiki/CodeReviewComments#named-result-parameters https://github.com/golang/go/wiki/CodeReviewComments#named-r...

laumars 9y ago
I don't think naked returns are any more magical than when you just drop a variable name in there. Either way, when you read a return statement you'll want to re-read the code to find the context of that return. The only difference is with named returned the variable is declared in the function declaration rather than the body of code. So it's definitely just a preference thing there. My coding style is to try and avoid lengthy functions - my procedural code is definitely inspired by the functional paradigm. Granted it's not always possibly to avoid a long function but for the shorter ones named returns tend to produce cleaner looking code _in my opinion_. In any case, I will definitely take your points on board and be more mindful about when using named returns - ie think about whether they're adding to the readability or if I'm just being lazy saving myself a var declaration. Thank you for the reference article as well.
- KirinDave 9y ago
  > Either way, when you read a return statement you'll want to re-read the code to find the context of that return. That's the ugly part of this feature. It adds one more place where you need to check. Also my hair gets paler and my body grows weak thinking about using defer with named return values. Isn't Go supposed to easy to read? Isn't that like it's principle virtue?

by cyphar 9y ago

laumars 9y ago

I don't think naked returns are any more magical than when you just drop a variable name in there. Either way, when you read a return statement you'll want to re-read the code to find the context of that return. The only difference is with named returned the variable is declared in the function declaration rather than the body of code. So it's definitely just a preference thing there. My coding style is to try and avoid lengthy functions - my procedural code is definitely inspired by the functional paradigm. Granted it's not always possibly to avoid a long function but for the shorter ones named returns tend to produce cleaner looking code _in my opinion_. In any case, I will definitely take your points on board and be more mindful about when using named returns - ie think about whether they're adding to the readability or if I'm just being lazy saving myself a var declaration. Thank you for the reference article as well.

KirinDave 9y ago
> Either way, when you read a return statement you'll want to re-read the code to find the context of that return. That's the ugly part of this feature. It adds one more place where you need to check. Also my hair gets paler and my body grows weak thinking about using defer with named return values. Isn't Go supposed to easy to read? Isn't that like it's principle virtue?