Go Naming Conventions: A Practical Guide
alexedwards.net
Go Naming Conventions: A Practical Guide
1–10 of 77 posts
Re: Go Naming Conventions: A Practical Guide
#2Another of mine: don't name a struct after an interface method that it's supposed to implement. If you have a package linearalgebra, then making a custom error type linearalgebra.LinearAlgebraError is too "chatty" but linearalgebra.Error will cause you pain if it implements "Error string()", as it probably should, and you decide to make a linearalgebra.MatrixSingularError that wraps a linearalgebra.Error to "inherit" its methods.
In the end, it ended up called linearalgebra.Err .
P.S Alex Edwards' "let's go" and "let's go further" are great books to get someone up to date with golang, just keep an eye on features that are newer than the book(s).
Re: Go Naming Conventions: A Practical Guide
#3[flagged]
Re: Go Naming Conventions: A Practical Guide
#4[flagged]
You can use this article to guide your choice of rulesets. And you still have to exert some artisan labor to develop any taste.
Parochialism here is saying “just use AI” in disguise.
Re: Go Naming Conventions: A Practical Guide
#5[flagged]
> this seems anachronistic, written for a human artisan laboring over each naming choice directly
Some of us want to write well thought-through code, rather than letting an AI just spew poorly thought-through unmaintainable shit.
Re: Go Naming Conventions: A Practical Guide
#6Another of mine: don't name a struct after an interface method that it's supposed to implement. If you have a package linearalgebra, then making a custom error type linearalgebra.LinearAlgebraError is too "chatty" but linearalgebra.Error will cause you pain if it implements "Error string()", as it probably should, and you decide to make a linearalgebra.MatrixSingularError that wraps a linearalgebra.Error to "inherit"…
The booms receive regular updates. I got an email about an update to Let’s Go Further on 3/12 for Go 1.26
Re: Go Naming Conventions: A Practical Guide
#7I like this article — short, accurate (which is somehow not a given these days...) and useful, just like Go language itself.
Re: Go Naming Conventions: A Practical Guide
#8I was surprised to see literally invalid names in the "bad" section, e.g. "Cannot start with a digit". Why even presenting this if it's rejected by the compiler?
Re: Go Naming Conventions: A Practical Guide
#9[flagged]
[flagged]
Re: Go Naming Conventions: A Practical Guide
#10I was surprised to see literally invalid names in the "bad" section, e.g. "Cannot start with a digit". Why even presenting this if it's rejected by the compiler?
The example with the dash in it confused me as well.