FAQ
stupid question: what is an "acceptable" number of return values from a
function? Is it ok to have a function with 10 return values? Any guideline?

Thanks,
Daniele

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Search Discussions

  • Jan Mercl at May 26, 2013 at 7:45 am

    On Sun, May 26, 2013 at 9:38 AM, wrote:
    what is an "acceptable" number of return values from a
    function? Is it ok to have a function with 10 return values? Any guideline?
    42.

    Okay, now seriously. Never seen any Go code using 10 return values.
    Not sure if I've seen 5 return values. I'd estimate that up to 3, to
    maybe 4 return values are just common. Above that I'd guess there's
    some better way how to design the code. However, it's definitely
    specific to a real code piece. One would have to first see the 10
    return values monster to be able to give it a fair judgement ;-)

    -j

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Pala Daniele at May 26, 2013 at 8:34 am
    Well, I don't have a 10 values example :-)
    I just have this function, with 4 and a half return values:

      // ReadTOSI is the same as Read, but it also indicates if the data
    comes

      // from an expedited TPDU, and if it is the end of a
    TSDU.

      func (c *TOSIConn) ReadTOSI(b []byte) (n int, err error, expedited, end
    bool) {

    the half is the buffer b, since it is both an input and an output. :-)
    I was thinking that, since "n", "expedited", and "end" are all information
    about the data returned in the buffer b, it would be more correct to pack
    them inside a struct, like this:

      type ReadInfo struct {
          N int
          Expedited, End bool
      }

    so that I have

      func (c *TOSIConn) ReadTOSI(b []byte) (ReadInfo, err error) {

    ...maybe this can be the guideline about return values.

    Regards,
    Daniele

    Il giorno domenica 26 maggio 2013 09:45:30 UTC+2, Jan Mercl ha scritto:
    On Sun, May 26, 2013 at 9:38 AM, <pala.d...@gmail.com <javascript:>>
    wrote:
    what is an "acceptable" number of return values from a
    function? Is it ok to have a function with 10 return values? Any
    guideline?

    42.

    Okay, now seriously. Never seen any Go code using 10 return values.
    Not sure if I've seen 5 return values. I'd estimate that up to 3, to
    maybe 4 return values are just common. Above that I'd guess there's
    some better way how to design the code. However, it's definitely
    specific to a real code piece. One would have to first see the 10
    return values monster to be able to give it a fair judgement ;-)

    -j
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Michael Jones at May 26, 2013 at 12:39 pm
    Go is happy with as many as you want. If it was me, I'd be thinking about
    the documentation and the most natural result for the caller:

    Do they need N independent values or would a struct of values make more
    sense?

    Should the N independent values come from one call's return values or are
    they logically two or three groups of values that should come from two or
    three function returns.


    As an example, a function on CARs that returned the driver's name, would
    have one string return value. But a function on VEHICLES that returns the
    people with driver's licenses, should send back an array if the vehicle
    might be a bus or airplane.

    On Sun, May 26, 2013 at 1:34 AM, wrote:

    Well, I don't have a 10 values example :-)
    I just have this function, with 4 and a half return values:

    // ReadTOSI is the same as Read, but it also indicates if the data
    comes

    // from an expedited TPDU, and if it is the end of a
    TSDU.

    func (c *TOSIConn) ReadTOSI(b []byte) (n int, err error, expedited, end
    bool) {

    the half is the buffer b, since it is both an input and an output. :-)
    I was thinking that, since "n", "expedited", and "end" are all information
    about the data returned in the buffer b, it would be more correct to pack
    them inside a struct, like this:

    type ReadInfo struct {
    N int
    Expedited, End bool
    }

    so that I have

    func (c *TOSIConn) ReadTOSI(b []byte) (ReadInfo, err error) {

    ...maybe this can be the guideline about return values.

    Regards,
    Daniele

    Il giorno domenica 26 maggio 2013 09:45:30 UTC+2, Jan Mercl ha scritto:
    On Sun, May 26, 2013 at 9:38 AM, wrote:

    what is an "acceptable" number of return values from a
    function? Is it ok to have a function with 10 return values? Any
    guideline?

    42.

    Okay, now seriously. Never seen any Go code using 10 return values.
    Not sure if I've seen 5 return values. I'd estimate that up to 3, to
    maybe 4 return values are just common. Above that I'd guess there's
    some better way how to design the code. However, it's definitely
    specific to a real code piece. One would have to first see the 10
    return values monster to be able to give it a fair judgement ;-)

    -j
    --
    You received this message because you are subscribed to the Google Groups
    "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an
    email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.



    --
    Michael T. Jones | Chief Technology Advocate | mtj@google.com | +1
    650-335-5765

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Tobia at May 26, 2013 at 10:41 pm

    func (c *TOSIConn) ReadTOSI(b []byte) (n int, err error, expedited, end
    bool) {
    This looks all right.

    func (c *TOSIConn) ReadTOSI(b []byte) (ReadInfo, err error) {
    >

    This looks fine too, although slightly more opaque.

    I think it's more important to pick one style and stick to it throughout
    your whole API, although it depends on how much you value consistency<http://en.wikipedia.org/wiki/Worse_is_better>
    .

    Tobia

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedMay 26, '13 at 7:38a
activeMay 26, '13 at 10:41p
posts5
users4
websitegolang.org

People

Translate

site design / logo © 2022 Grokbase