Named or unnamed struct initialisation? What is best practice?

[snmed]

Hi gophers

I've a litte question about best practice for struct initialisation.  For example one can initialise structs like:

type A struct {

   name      string

   firstName string

}

a1 := A{"Mueller", "Max"}

a2 := A{name: "Mueller", firstName: "Max"}

The first one is concise and intuitive, but the second is more robust in case of refactoring.
If anyone adds a string field at the beginning of the struct, it compiles fine but changes the meaning of all initialised structs in the project, if nobody 

pays attention to that.

Is there any best practice or advises how structs should be initialised and/or refactored?

Cheers

[Tamás Gulácsi]

Named.

[snmed]

Okay thanks, as I supposed. Personally i used always named initialisation despite of the overhead, but sometimes I feel the urge to use the short unamed initialisation. ;-)

Am Mittwoch, 5. Juli 2017 07:41:04 UTC+2 schrieb Tamás Gulácsi:

Named.

[r...@skyportsystems.com]

for some of our sensitive structures that are tricky and have multiple fields of the same type, there is a trick you can use:

type bar struct {

   A int

   _ bool

}

see https://play.golang.org/p/rFKGoKq-S9

[Dan Kortschak]

On Wed, 2017-07-05 at 17:26 -0700, rsr via golang-nuts wrote:
> type bar struct {
>    A int
>    _ bool
> }

or `type bar struct { A int; _ [0]byte }` to avoid the additional byte use.

[snmed]

Hi rob

Thanks for your response. I didn't know that trick, but it seems to me a little bit ugly to guard fields that way. I will stick to named initialisations and write it as a policy into the style guide.

Cheers

[Robert Rodgers]

nice.

[Rader Lei]

they both have the same size, eg. following structs bar and bar2 both take 16 bytes memory on a x64 machine.

package main

import (

    "fmt"

    "unsafe"

)

type bar struct {

    A int

    _ bool

}

type bar2 struct {

    A int

    _ [0]byte

}

func main() {

    bar := bar{}

    bar2 := bar2{}

    fmt.Printf("size of bar:%v\n", unsafe.Sizeof(bar))

    fmt.Printf("size of bar2:%v\n", unsafe.Sizeof(bar2))

}

[Rader]

I found the position of `[0]byte` in the struct matters. 

 type bar2 struct {

A int

_ [0]byte

}

differs from

type bar3 struct {

_ [0]byte

A int

}

see the full example

[Matthew Zimmerman]

Why not use struct{}?  Is what is recommended for maps to notate a set (only the keys mean something).

https://play.golang.org/p/fxtEWejqdh

--
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...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Rader]

sure you can. no memory space difference.

[Dmitriy Cherchenko]

Can you do a test to see if there's a performance difference?

[Dan Kortschak]

Both are used.

[Dan Kortschak]

Yes, trailing zero-size elements affect the size.

https://play.golang.org/p/Ox0FJX3C5V

https://github.com/golang/go/commit/6f07ac2f280847ee0346b871b23cab90869f84a4

[roger peppe]

Sometimes I'll use non-named-member initialisation for

small structs with a well known set of fields (for example,

a Point with X and Y coordinates), but otherwise I much

prefer named initialisation (go vet will warn if you don't, in fact).

I'll almost always put each field onto its own line too - I think

it's more readable that way.

For example:

a2 := A{

name: "Mueller",

firstName: "Max",

}

It's easier to add new members that way, and the

line is shorter.

  cheers,

    rog.

--

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.