On: Benefits of named return values in Go

[pfarnsworth]

I actually hate named return values. I'm relatively new to Go, but I like some of the ideas about it. Named return values is something about Go that I despise because it is absolutely misused in my opinion. For such an opinionated language, with some opinions that I don't agree with, this is one that I vehemently disagree with.

It makes the code a lot harder to read, and you need to keep more memorized "magic" in your head. For example, you can't just look at the return values to figure out what a function returns, now you need to look to see if the return values are named, and then trace through that.

I very much prefer explicit code as opposed to implicit code, especially on a day-to-day basis. It just makes my life a lot easier in the long run.

[nickcw → pfarnsworth]

I think you are talking about bare returns, which are somewhat orthogonal to named return values.

You can use non-bare returns with named return values, just mention the names in the return statement. This compiles to the same code as the bare return.

I'm a bit ambivalent about bare returns, but named return values are useful, especially in the presence of defer statements.

[darccio → pfarnsworth]

I feel the opposite way. I always use named return values because I feel the code is less cluttered and less magic. I just look at the first line of a function and I know what variables are used as return.

I think they are pretty explicit and simpler, because there are defined in a single point of our code. Anyway, we probably have different backgrounds :)

Although it wasn't your point, what I don't like is mixing bare and named return. I think it's better to stick to one style or the other.

[ramenmeal → pfarnsworth]

Its a good point. Especially since one of go's mantra's is simplicity.