alt Hacker NewsGo Naming Conventions: A Practical Guide
Comments
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?
People have been arguing this stuff since the dawn of (computer) time. I don't get it. I've been at it so long now, IDGAF what or how you name something. Short names in loops? Long? I don't care. I really don't. Just be consistent in what you decide and I can read it.
All this arguing... FFS, go DO something with your time!
EDIT: Oh, yeah, as for the article itself, it's a good article. But again, just be consistent in what you choose.
I like this article — short, accurate (which is somehow not a given these days...) and useful, just like Go language itself.
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).
This is great! My team started using Go last year so I fed this article to set off a fleet of agents on our Go codebase and generate a report out w/ code samples based on it. Ended up with a pretty good little document to present on Monday :)
> Words that are acronyms or initialisms (like API, URL or HTTP) should use a consistent case within the identifier. So, for example, apiKey or APIKey are conventional, but ApiKey is not. This rule also applies to ID when it is used as shorthand for the words "identity" or "identifier" — so that means write userID rather than userId.
Outdated.
Over time, it's become clear that breaking the camelCase convention in this manner is inappropriate:
- The inconsistency with the convention is jarring, consider `APIURL` - is that a variable (ApiUrl) or a constant (APIURL)?
- The inconsistency introduces doubt on how to write any given identifier - which is why the above advice even needs to exist
- The whole point of the convention is to make separate parts of the name visually separate, consider `someAPIURLHTMLJSONExtension` vs `someApiUrlHtmlJsonExtension`
- It's hard to keep this consistent - we may reasonably disagree whether `ID` should be capitalized or not, meaning you may just as well find both `ID` and `id` across codebases. This erases the benefits of capitalization altogether.
The benefits of keeping these acronyms capitalized are dubious and don't outweigh the downsides.
And of course, the real solution is to use the one correct naming convention - `snake_case`. Then you can capitalize all you want without trouble - `some_API_URL_HTML_JSON_extension`.
[dead]
[dead]
> we use the identifier p to represent a value in the people slice — the range block is so small and tight that using a single letter name is clear enough.
No, it's not. When you see `p.Age`, you have to go back and find the body of the loop, see what it operates on and decipher what p stands for. When you see `person.Age`, you understand it. I've never understood what is gained by using `p` instead of spelling it out as `person`.