5 ms·

I look at these result functions and all I can think is, "Wow, it must be really delightful when you get a zero record back and what to know why your parser has

I look at these result functions and all I can think is, "Wow, it must be really delightful when you get a zero record back and what to know why your parser has a bug." I really hope these are didactic in nature and not a representation of industry best practice. Why not just declare a record in scope and return that? Why rely on a sneaky little piece of syntax tucked away in the return value? Aren't gophers supposed to be all about a regular language with few surprises?

weberc2 9y ago
For the most part named returns are frowned upon, and while it is admittedly an oddity in the language, having one oddity is still achieving the stated goal of "few surprises". :)
- laumars 9y ago
  Are they actually frowned upon? I've been writing Go for a few years now and while I acknowledge there will be blind spots in my knowledge, this is still the first I've heard against using that language feature. In fact named returns appear all over the Go source code itself[0] and the Effective Go section on named returns[1] seems positive about their usage. [0] https://github.com/golang/go/blob/master/src/os/file.go https://github.com/golang/go/blob/master/src/os/file.go (file taken at random) [1] https://golang.org/doc/effective_go.html#named-results https://golang.org/doc/effective_go.html#named-results Personally I use named returns heavily because it helps document what each return is used for. Which is particularly useful in IDEs like IntelliJ where you get the tooltip popup with the function parameters and returns. But frankly I find named returns just as useful when reading back old code on GitHub or even just in vi. I also notice I'm not the only one who uses them in production code. Here are some popular packages by other talented Go developers (all .go files picked at random)[2][3]: [2] https://github.com/kr/pty/blob/master/util.go https://github.com/kr/pty/blob/master/util.go (this package creates UNIX PTY files) [3] https://github.com/chzyer/readline/blob/master/operation.go https://github.com/chzyer/readline/blob/master/operation.go (readline package used by cockroachdb and Netflix) In fact of the packages I checked, I could only find one package that didn't make heavy use of named returns[4] [4] https://github.com/go-sql-driver/mysql/ https://github.com/go-sql-driver/mysql/ So if they are frowned upon, I'd be interested to know more about who and why.
  - 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?
  - justinclift 9y ago
    Definitely agreed. Since getting into using Gogland (the JetBrains Go IDE), I'm using named return values much more because the name is useful in the pop-up help. I don't need to look up function docs anywhere near as often.
cyphar 9y ago
> Why not just declare a record in scope and return that? Why rely on a sneaky little piece of syntax tucked away in the return value? Aren't gophers supposed to be all about a regular language with few surprises? It's not a sneaky piece of syntax, in fact it is required to use that syntax if you want to reference or modify the return value of a function in a deferred function call. I don't like the syntax and hate that Go forces you to use it in the above case, but it's definitely not sneaky syntax. Any regular Go developer should be expected to know about this construct.
- KirinDave 9y ago
  If you have long function and the addition of a single character up top at the right changes the behavior of the return keyword? I've hated this feature since I learned about it. Its existence is one of the many reasons I dismiss arguments about Go being easy to read.

weberc2 9y ago

For the most part named returns are frowned upon, and while it is admittedly an oddity in the language, having one oddity is still achieving the stated goal of "few surprises". :)

laumars 9y ago
Are they actually frowned upon? I've been writing Go for a few years now and while I acknowledge there will be blind spots in my knowledge, this is still the first I've heard against using that language feature. In fact named returns appear all over the Go source code itself[0] and the Effective Go section on named returns[1] seems positive about their usage. [0] https://github.com/golang/go/blob/master/src/os/file.go https://github.com/golang/go/blob/master/src/os/file.go (file taken at random) [1] https://golang.org/doc/effective_go.html#named-results https://golang.org/doc/effective_go.html#named-results Personally I use named returns heavily because it helps document what each return is used for. Which is particularly useful in IDEs like IntelliJ where you get the tooltip popup with the function parameters and returns. But frankly I find named returns just as useful when reading back old code on GitHub or even just in vi. I also notice I'm not the only one who uses them in production code. Here are some popular packages by other talented Go developers (all .go files picked at random)[2][3]: [2] https://github.com/kr/pty/blob/master/util.go https://github.com/kr/pty/blob/master/util.go (this package creates UNIX PTY files) [3] https://github.com/chzyer/readline/blob/master/operation.go https://github.com/chzyer/readline/blob/master/operation.go (readline package used by cockroachdb and Netflix) In fact of the packages I checked, I could only find one package that didn't make heavy use of named returns[4] [4] https://github.com/go-sql-driver/mysql/ https://github.com/go-sql-driver/mysql/ So if they are frowned upon, I'd be interested to know more about who and why.
- 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?
- justinclift 9y ago
  Definitely agreed. Since getting into using Gogland (the JetBrains Go IDE), I'm using named return values much more because the name is useful in the pop-up help. I don't need to look up function docs anywhere near as often.

cyphar 9y ago

> Why not just declare a record in scope and return that? Why rely on a sneaky little piece of syntax tucked away in the return value? Aren't gophers supposed to be all about a regular language with few surprises? It's not a sneaky piece of syntax, in fact it is required to use that syntax if you want to reference or modify the return value of a function in a deferred function call. I don't like the syntax and hate that Go forces you to use it in the above case, but it's definitely not sneaky syntax. Any regular Go developer should be expected to know about this construct.

KirinDave 9y ago
If you have long function and the addition of a single character up top at the right changes the behavior of the return keyword? I've hated this feature since I learned about it. Its existence is one of the many reasons I dismiss arguments about Go being easy to read.