FAQ
1. What is the preferred style for checking if v (a bool) is not true:
if !v {...} or if v == false {…}

2. What is the preferred style for handling the return values of a call to a
function like: func someFunc() (bool, err) {…}

v, err := someFunc()
if err != nil {
//do something
         }
If v {
// do something else
}

Or…

if v, err := someFunc(); err != nil {
// do something
} else if v {
// do something else
}

I know these a simple cases, but I have them a lot and would like to write
them following the Go best praktisch…

Thx!


--
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/d/optout.

Search Discussions

  • Jesse McNelis at Aug 4, 2014 at 9:31 am

    On Mon, Aug 4, 2014 at 7:24 PM, Sander van Harmelen wrote:
    1. What is the preferred style for checking if v (a bool) is not true:
    if !v {...} or if v == false {…} if !v {}
    2. What is the preferred style for handling the return values of a call to a
    function like: func someFunc() (bool, err) {…}

    v, err := someFunc()
    if err != nil {
    //do something
    }
    You don't need to check 'v' usually, it should be valid if err is nil.
    Use this one when you have two return values.
    Or…

    if v, err := someFunc(); err != nil {
    // do something
    } else if v {
    // do something else
    }
    This one gets tricky when you have more than one return value, it's
    great for functions that just return an error.
    In most cases the convention is not to use an 'else'.

    For more style conventions:
    https://code.google.com/p/go-wiki/wiki/CodeReviewComments



    --
    =====================
    http://jessta.id.au

    --
    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/d/optout.
  • Sander van Harmelen at Aug 4, 2014 at 10:27 am
    Thx!

    And checking ‘v’ in this case makes sense as I only want to run a certain
    part of the code when ‘v’ == true.

    S.

    On 04/08/2014 11:31:09, "Jesse McNelis" wrote:
    On Mon, Aug 4, 2014 at 7:24 PM, Sander van Harmelen wrote:
    1. What is the preferred style for checking if v (a bool) is not true:
    if !v {...} or if v == false {…} if !v {}
    2. What is the preferred style for handling the return values of a call
    to a
    function like: func someFunc() (bool, err) {…}

    v, err := someFunc()
    if err != nil {
    //do something
    }
    You don't need to check 'v' usually, it should be valid if err is nil.
    Use this one when you have two return values.
    Or…

    if v, err := someFunc(); err != nil {
    // do something
    } else if v {
    // do something else
    }
    This one gets tricky when you have more than one return value, it's
    great for functions that just return an error.
    In most cases the convention is not to use an 'else'.

    For more style conventions:
    https://code.google.com/p/go-wiki/wiki/CodeReviewComments



    --
    =====================
    http://jessta.id.au

    --
    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/d/optout.

    --
    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/d/optout.
  • Peter Bourgon at Aug 4, 2014 at 10:35 am
    A good rule is to keep all of your declarations bound to the smallest
    scope possible. That is, assuming you only use `v` to conditionally
    execute some block of code, prefer this style:

      if v, err := foo(); err != nil {
          // handle error
      } else if v {
          // block of code
      }

    If (and only if) you need to use `v` later on in the same enclosing
    scope, you can use this form:

      v, err := foo()
      if err != nil {
          // handle error
      }
      if v {
          // block of code
      }
      // ...
      return v // or whatever



    On Mon, Aug 4, 2014 at 11:31 AM, Jesse McNelis wrote:
    On Mon, Aug 4, 2014 at 7:24 PM, Sander van Harmelen wrote:
    1. What is the preferred style for checking if v (a bool) is not true:
    if !v {...} or if v == false {…} if !v {}
    2. What is the preferred style for handling the return values of a call to a
    function like: func someFunc() (bool, err) {…}

    v, err := someFunc()
    if err != nil {
    //do something
    }
    You don't need to check 'v' usually, it should be valid if err is nil.
    Use this one when you have two return values.
    Or…

    if v, err := someFunc(); err != nil {
    // do something
    } else if v {
    // do something else
    }
    This one gets tricky when you have more than one return value, it's
    great for functions that just return an error.
    In most cases the convention is not to use an 'else'.

    For more style conventions:
    https://code.google.com/p/go-wiki/wiki/CodeReviewComments



    --
    =====================
    http://jessta.id.au

    --
    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/d/optout.
    --
    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/d/optout.
  • Sander van Harmelen at Aug 4, 2014 at 10:42 am
    That’s a clear rule… Thanks for that.
    On 04/08/2014 12:35:14, "Peter Bourgon" wrote:

    A good rule is to keep all of your declarations bound to the smallest
    scope possible. That is, assuming you only use `v` to conditionally
    execute some block of code, prefer this style:

    if v, err := foo(); err != nil {
    // handle error
    } else if v {
    // block of code
    }

    If (and only if) you need to use `v` later on in the same enclosing
    scope, you can use this form:

    v, err := foo()
    if err != nil {
    // handle error
    }
    if v {
    // block of code
    }
    // ...
    return v // or whatever



    On Mon, Aug 4, 2014 at 11:31 AM, Jesse McNelis wrote:
    On Mon, Aug 4, 2014 at 7:24 PM, Sander van Harmelen <sander@xanzy.io>
    wrote:
    1. What is the preferred style for checking if v (a bool) is not true:
    if !v {...} or if v == false {…} if !v {}
    2. What is the preferred style for handling the return values of a
    call to a
    function like: func someFunc() (bool, err) {…}

    v, err := someFunc()
    if err != nil {
    //do something
    }
    You don't need to check 'v' usually, it should be valid if err is nil.
    Use this one when you have two return values.
    Or…

    if v, err := someFunc(); err != nil {
    // do something
    } else if v {
    // do something else
    }
    This one gets tricky when you have more than one return value, it's
    great for functions that just return an error.
    In most cases the convention is not to use an 'else'.

    For more style conventions:
    https://code.google.com/p/go-wiki/wiki/CodeReviewComments



    --
    =====================
    http://jessta.id.au

    --
    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/d/optout.

    --
    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/d/optout.
  • Sander van Harmelen at Aug 4, 2014 at 11:39 am
    And does this rule hold when you are at the end of your function and need
    to return something? I see the following 3 options here:

    1.
    <snip>
       p, err := foo() // p is a pointer here!
       if err != nil {
         return nil, err
       }
       return p, nil
    }


    2.
    <snip>

       if p, err := foo(); err != nil { // p is a pointer here!
         return nil, err
       } else {
         return p, nil
       }
    }



    3.
    <snip>
       return foo()
    }


    This last one can of course return something strange/bad for p next to the
    error, so error checking is than vital in the calling function. But maybe
    that’s obvious and doesn’t matter?

    I don’t know if these are stupid questions, but I would like follow the
    most preferred Go style as much as possible and I fail to find any
    guidelines on these cases…

    On 04/08/2014 12:35:14, "Peter Bourgon" wrote:

    A good rule is to keep all of your declarations bound to the smallest
    scope possible. That is, assuming you only use `v` to conditionally
    execute some block of code, prefer this style:

    if v, err := foo(); err != nil {
    // handle error
    } else if v {
    // block of code
    }

    If (and only if) you need to use `v` later on in the same enclosing
    scope, you can use this form:

    v, err := foo()
    if err != nil {
    // handle error
    }
    if v {
    // block of code
    }
    // ...
    return v // or whatever



    On Mon, Aug 4, 2014 at 11:31 AM, Jesse McNelis wrote:
    On Mon, Aug 4, 2014 at 7:24 PM, Sander van Harmelen <sander@xanzy.io>
    wrote:
    1. What is the preferred style for checking if v (a bool) is not true:
    if !v {...} or if v == false {…} if !v {}
    2. What is the preferred style for handling the return values of a
    call to a
    function like: func someFunc() (bool, err) {…}

    v, err := someFunc()
    if err != nil {
    //do something
    }
    You don't need to check 'v' usually, it should be valid if err is nil.
    Use this one when you have two return values.
    Or…

    if v, err := someFunc(); err != nil {
    // do something
    } else if v {
    // do something else
    }
    This one gets tricky when you have more than one return value, it's
    great for functions that just return an error.
    In most cases the convention is not to use an 'else'.

    For more style conventions:
    https://code.google.com/p/go-wiki/wiki/CodeReviewComments



    --
    =====================
    http://jessta.id.au

    --
    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/d/optout.

    --
    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/d/optout.
  • peterGo at Aug 4, 2014 at 12:28 pm
    Sander,

    The problem with many of these foo-bar abstractions is that they lack
    context, for example, case 2. If we provide the likely context, case 2
    becomes:

         // 2. What is the preferred style for handling the return values of a
    call to a function like: func someFunc() (bool, err) {…}
         {
             // a.
             v, err := someFunc()
             if err != nil {
                 // do error something
                 return err
             }
             if v {
                 // do true something
             }
         }
         // Or …
         {
             // b.
             if v, err := someFunc(); err != nil {
                 // do error something
                 return err
             } else if v {
                 // do true something
             }
         }

    As a general principle, unless the primary purpose is error handling, write
    code that reads easily for the non-error case, that is, the error case can
    easily be skipped or ignored when reading the code. Since it's easiest to
    skip the three obvious lines of "err != nil" code in example 2.a. rather
    than disentangling the " err != nil" code in example 2.b., I prefer case
    2.a.

    For case 1, change v to a meaningful name, for example, empty. Then empty
    or !empty reads better than empty == true or empty == false.

    Peter
    On Monday, August 4, 2014 5:24:47 AM UTC-4, Sander van Harmelen wrote:

    1. What is the preferred style for checking if v (a bool) is not true:
    if !v {...} or if v == false {…}

    2. What is the preferred style for handling the return values of a call to
    a function like: func someFunc() (bool, err) {…}

    v, err := someFunc()
    if err != nil {
    //do something
    }
    If v {
    // do something else
    }

    Or…

    if v, err := someFunc(); err != nil {
    // do something
    } else if v {
    // do something else
    }

    I know these a simple cases, but I have them a lot and would like to write
    them following the Go best praktisch…

    Thx!
    --
    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/d/optout.
  • Sander van Harmelen at Aug 4, 2014 at 1:23 pm
    Makes sense… So I think I'll just have to try to ignore my OCD a little and
    use the best option for a specific use case/context, instead of trying to
    always follow the same pattern for all different use cases :)

    From: peterGo <go.peter.90@gmail.com>
    Date: Monday 4 August 2014 14:28:00
    To: "golang-nuts@googlegroups.com" <golang-nuts@googlegroups.com>
    Subject: [go-nuts] Re: 2 small questions about style...

    Sander,

    The problem with many of these foo-bar abstractions is that they lack
    context, for example, case 2. If we provide the likely context, case 2
    becomes:

         // 2. What is the preferred style for handling the return values of a
    call to a function like: func someFunc() (bool, err) {…}
         {
             // a.
             v, err := someFunc()
             if err != nil {
                 // do error something
                 return err
             }
             if v {
                 // do true something
             }
         }
         // Or …
         {
             // b.
             if v, err := someFunc(); err != nil {
                 // do error something
                 return err
             } else if v {
                 // do true something
             }
         }

    As a general principle, unless the primary purpose is error handling, write
    code that reads easily for the non-error case, that is, the error case can
    easily be skipped or ignored when reading the code. Since it's easiest to
    skip the three obvious lines of "err != nil" code in example 2.a. rather
    than disentangling the " err != nil" code in example 2.b., I prefer case
    2.a.

    For case 1, change v to a meaningful name, for example, empty. Then empty or
    !empty reads better than empty == true or empty == false.

    Peter
    On Monday, August 4, 2014 5:24:47 AM UTC-4, Sander van Harmelen wrote:
    1. What is the preferred style for checking if v (a bool) is not true:
    if !v {...} or if v == false {…}

    2. What is the preferred style for handling the return values of a call to a
    function like: func someFunc() (bool, err) {…}

    v, err := someFunc()
    if err != nil {
    //do something
    }
    If v {
    // do something else
    }

    Or…

    if v, err := someFunc(); err != nil {
    // do something
    } else if v {
    // do something else
    }

    I know these a simple cases, but I have them a lot and would like to write
    them following the Go best praktisch…

    Thx!
    --
    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/d/optout.


    --
    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/d/optout.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedAug 4, '14 at 9:24a
activeAug 4, '14 at 1:23p
posts8
users4
websitegolang.org

People

Translate

site design / logo © 2021 Grokbase