5 ms·
Go Naming Conventions: A Practical Guide
- red_admiral 7mo agoAnother 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).
- DauntingPear7 7mo agoThe booms receive regular updates. I got an email about an update to Let’s Go Further on 3/12 for Go 1.26
- nacozarina 7mo ago[flagged]
- piekvorst 7mo agoYou 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.
- johneth 7mo ago> 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.
- andersonpico 7mo ago[flagged]
- jonathanstrange 7mo agoYou're making yourself redundant if you don't keep your actual programming skills sharp.
- ErroneousBosh 7mo ago> passed to the ai model for the code it generates AI can't generate code. It only copies it (badly) from somewhere else.
- nasretdinov 7mo agoI like this article — short, accurate (which is somehow not a given these days...) and useful, just like Go language itself.
- qezz 7mo agoI 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?
- 0x696C6961 7mo agoThe example with the dash in it confused me as well.
- alexfoo 7mo agoI wondered if you could sneak in some unicode digit but it seems to reject those too: $ go run z.go # command-line-arguments ./z.go:6:2: identifier cannot begin with digit U+0661 '١' ./z.go:7:27: identifier cannot begin with digit U+0661 '١' (I tried a few of them but not all.)
- pphysch 7mo ago"Chat, generate me a table of bad Golang making practices"
- alex_edwards 7mo agoAuthor here. The answer is because I mentioned it as one of the bullet pointed hard-rules, and I wanted to include an example to illustrate it.
- laserlight 7mo ago> 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`.
- piekvorst 7mo agoLong lines make reading rhythm uncomfortable (long jumps, prolonged eye movements) and long words make the text too dense and slow down the reading. It’s bad typography. I have heard an idea that a good variable should be understood by just reading its name, out of context. That would make “ProductIndex” superior to “i”, which doesn't add any clarity.
- monooso 7mo agoI would argue that ambiguity and uncertainty slow down reading, and more importantly comprehension, far more than a few additional characters.
- lokar 7mo agoIt depends on whom you are optimizing for. Someone who knows the language, but not this system/codebase, or someone who works in this area often?
- Joker_vD 7mo agoA good variable name is the one that is understood by reading it in context, which is why you don't have names like "current_person" or "CurrentIndexOfProductBeingUpdated".
- diath 7mo agoSomething like "AnIteratorObjectWithPersonPointer" would be a long word, "person" is absolutely not. If a 6 letter identifier causes you that much trouble with code being too verbose, then it's likely a screen resolution/density/font issue, not a naming issue. > That would make “ProductIndex” superior to “i”, which doesn't add any clarity. And then you introduce extra two levels of nested loops and suddenly "i", "j", and "k" don't make any sense on their own, but "ProductIndex", "BatchIndex" and "SeriesIndex" do.
- piekvorst 7mo ago[dead]
- deleted 7mo ago[deleted]
- jeninho 7mo ago[dead]
- HumblyTossed 7mo agoPeople 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.
- menno-sh 7mo agoThis 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 :)
- graynk 7mo agoWhy 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 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)
- voidfunc 7mo agoUsing a linter doesn't get you noticed by leadership and net you a promo.
- graynk 7mo agoSure 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.
- ManuelKiessling 7mo agoBetter yet, post about it on LinkedIn and explain what it taught you about marriage proposals!
- Mawr 7mo ago> 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`.
- syngrog66 7mo agoone rando set of opinions. stopped reading fast
- wpollock 7mo agoAllowing Unicode characters, then stating best practice is to stick with ASCII, is weird. (Go is not alone in this practice.) Unicode identifiers have a host of issues, such as some characters have no case distinction, some have title-case but not uppercase, some "capitalize" the last letter in a word and not the first (Hebrew has five "final form" letters), etc. Does Go specify the meaning (exported or not) if a letter has no case, or if an identifier starts with a zero-width joiner character? Without a huge list of detailled rules, too much is left to the implementation to decide. I prefer to stick with ASCII for names. Fun fact: When printing with movable type began, printers would travel with large "type cases" containing the small wood or metal blocks with glyphs on them. The ones the used frequently were kept in the lower half of the case, in easy reach. That's where the terms "lowercase" and "uppercase" come from.
- arcxi 7mo agoit is weird, especially for Go with its semantic naming and famously opinionated compiler. it will gladly build code with a variable named 𖤐界ᥱᥲΣ੭, but God forbid it's unused.
- layer8 7mo agoIt’s bad to disallow non-ASCII characters when programming for non-English business domains. The domain vocabulary often doesn’t translate well to English, or you need a glossary for someone familiar with the business domain to know which English term is supposed to mean which native business term. It’s just a pain. Conversely, transliterating the native term in ASCII can introduce ambiguities or be awkward or just plain weird for the native speaker. Of course, Unicode can be abused, but ASCII isn’t completely free of that either. (Maybe it tickles your fancy to name a variable _o0O0o_ or l1lIl1lIl1lIl1l.) If your native script doesn’t have upper and lower case, compromises may have to be made. We have to trust programmers to use good judgement.
- fragmede 7mo agoI believe https://imgur.com/dN9Nz3h https://imgur.com/dN9Nz3h is the canonical example of why full Unicode support is maybe not desirable.