I 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?
this seems anachronistic, written for a human artisan laboring over each naming choice directly
a modern approach would be a condensed ruleset passed to the ai model for the code it generates, and it should be straightforward to substitute different rulesets if you have a different taste in parochialisms.
Another 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).
a modern approach would be a condensed ruleset passed to the ai model for the code it generates, and it should be straightforward to substitute different rulesets if you have a different taste in parochialisms.
Some of us want to write well thought-through code, rather than letting an AI just spew poorly thought-through unmaintainable shit.
Parochialism here is saying “just use AI” in disguise.
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).