Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Go Naming Conventions: A Practical Guide

alexedwards.net

Post reply on HN
Print view View original

51–60 of 77 posts

Re: Go Naming Conventions: A Practical Guide

#51

Post by Mawr »

> 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`.

Re: Go Naming Conventions: A Practical Guide

#52

Post by gadflyinyoureye »

esrauch wrote: post #24
laserlight wrote: post #12

> 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 ou…

This is something that it seems some Go people just don't "believe" in my experience, that for some people that letter in that context is not mentally populated immediately. It's honestly a shame because it seems like Go is a good language but with such extremely opinionated style that is so unpleasant (not just single letters but other things stuff about tests aren't supposed to ever have helpers or test frameworks)…

I think the community is split on such things. I ended up telling the side that gets persnickety about short names and only using if statements in tests to pound sand. I use things that make my life easier. I now care less about some rude rando on r/golang than I did five years ago.

Re: Go Naming Conventions: A Practical Guide

#53

Post by hackthemack »

laserlight wrote: post #12

> 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 ou…

But what if your codebase has to interact with leads, customers, and another 3rd party system called Metrica with leads, customers?

When you write a loop, do you now name the variable

OurPerson.Age MetricaPerson.Age

?

What if, 3 years from now, you include another 3rd party vendor into the system and have to write code against that data and in the data they name their stuff OurPerson.Age?

Not saying you are wrong at all. Just naming things is hard and context dependent. I think that is why it is endlessly argued.

Re: Go Naming Conventions: A Practical Guide

#54

Post by giancarlostoro »

laserlight wrote: post #12

> 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 ou…

This comes from some dated idea for stuff like C where "its okay to use shorthands for variables" but is it really? The only place I allow it is simple iterators, but now we have enhanced loops where even this is unnecessary. We don't need to save on pixel screen space like if its still the 90s. Even with a simple 1080p monitor you can fit plenty of words and code.

Give your variables, functions, classes meaningful descriptive names that make sense to humans.

Re: Go Naming Conventions: A Practical Guide

#55

Post by graynk »

menno-sh wrote: post #48

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 :)

Why do you need AI agents for this?

You either catch and enforce it with a linter (e.g. https://golangci-lint.run/docs/linters/configuration/#revive) (in which case you don't need AI to tell you the current state, you just add the same config to all projects) or you don't enforce it (because everyone will forget unless it's automated)

Re: Go Naming Conventions: A Practical Guide

#56

Post by voidfunc »

graynk wrote: post #55
menno-sh wrote: post #48

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 :)

Why do you need AI agents for this? You either catch and enforce it with a linter (e.g. https://golangci-lint.run/docs/linters/configuration/#revive ) (in which case you don't need AI to tell you the current state, you just add the same config to all projects) or you don't enforce it (because everyone will forget unless it's automated)

Using a linter doesn't get you noticed by leadership and net you a promo.

Re: Go Naming Conventions: A Practical Guide

#57

Post by gopher_space »

laserlight wrote: post #50
zahlman wrote: post #44

Earlier quoted context omitted.

>you have to go back and find the body of the loop If the loop is long enough that you don't naturally remember how it was introduced, that's the problem. In the given example, the use of `p.Age` is literally on the next line of code after ` for _, p := range people`. > I've never understood what is gained by using `p` instead of spelling it out as `person`. Wisdom I received from, IIRC, the Perl documentation decade…

> remember how it was introduced The problem is that many times I have not read the definition to remember. Debugger puts me into a context where I have to figure out what `p` stands for. I go up the call stack and now there's `s` to be deciphered. Worse is the reuse of `p` for person, product, part, etc. in different contexts. Debugging is not the only problem. Code is read rarely linearly. Many times I browse diffe…

> Debugger puts me into a context where I have to figure out what `p` stands for.

`p` stands for "the process in question".

I like to think of single-character vars as idea or topic headers that track the single thing I'm currently up to. I'm rarely working with more than one at a time, frequently it's the only variable, and there are contexts where I wouldn't use them at all.

IMHO if you're in a situation where `p` isn't obvious to you, "something has gone wrong".

Re: Go Naming Conventions: A Practical Guide

#59

Post by graynk »

voidfunc wrote: post #56
graynk wrote: post #55

Earlier quoted context omitted.

Why do you need AI agents for this? You either catch and enforce it with a linter (e.g. https://golangci-lint.run/docs/linters/configuration/#revive ) (in which case you don't need AI to tell you the current state, you just add the same config to all projects) or you don't enforce it (because everyone will forget unless it's automated)

Using a linter doesn't get you noticed by leadership and net you a promo.

Sure it does, just say you "established org-wide coding standards and drove adoption of automated linting tooling, reducing review friction and enforcing style consistency at scale" in your assessment.

Re: Go Naming Conventions: A Practical Guide

#60

Post by bborud »

functional_dev wrote: post #45
zer00eyz wrote: post #37

Earlier quoted context omitted.

> I think this may be related to how people read code. You have people who scan shapes, and then you have people who read code almost like prose. I think this is an astute observation. I think there is another category of "reading" that happens, is what you're reading for "interaction" or "isolation". Sure c.method is a scalable shape but if your system deals with Cats, Camels, Cars, and Crabs that same c.method when…

The shape argument works well in small packages but it starts to fail once you have multiple domain models starting with the same letter

I wasn’t talking about just symbols but entire paragraphs of code as well.
Post reply on HN