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.
On 5 July 2017 at 06:17, snmed <sandro.p.da...@gmail.com> wrote:
> 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
>
> --
> 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+unsubscr...@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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
