Go Naming Conventions: A Practical Guide

28 points by cgrinds

telemachus

Some other links on naming conventions and rules in Go.

Andrew Gerrand "What's in a Name?" (slides for a general talk from 2014 about naming in Go)
Sameer Ajmani "Package Names" (post from 2015 with package naming recommendations)
Andrey Petrov "Neither self nor this: Receivers in Go" (post from 2016 that talks more about why you should avoid self or this for receiver names in Go)
Peter Bourgon "Go naming tips" (post from 2019 that recommends using specific word types for structs, interfaces, and functions)

michiel

I'm always amazed that there are so many people who look at the tiny degree of expressive freedom programming languages offer, and go: "No, we can't have that. Let's make sure there are Rules for that."

Nobody really has a problem naming variables. Non-ASCII characters were allowed by the spec from the first versions of Go, maybe they were intended to be used? Excluding them in the spec would've been much more easy.

These guides don't solve a problem that's not in their authors' heads.
- telemachus
  
  I'm more interested in the community norms rather than strict rules. If a critical mass of people follow the norms, then code is easier to read because things leap out at you and easier to write because certain choices are effectively made for you.
  
  Nobody really has a problem naming variables.
  
  Really? I thought naming was one of the two famous problems in computer science.
- icholy
  
  Found the guy who uses snake_case in Go.
  - ale
    
    Forcing style rules is classic webdev pampering though
    
    icholy
    
    When I write papers, I use different fonts on every page like a real man.
    
    ale
    
    You don’t write paper be honest with yourself
    
    icholy
    
    My guy, you're struggling to write a sentence...
    
    ale
    
    Found the webdev
    
    icholy
    
    Oof, illiterate and unoriginal.
    
    aoeu
    
    Why stop there? I make sure to use grammar-based syntax highlighting on the natural language, and change color themes every paragraph. I can easily speed-read 100wpm faster than the next guy with these enhancements.
    
    bitshift
    
    I'd like to suggest a middle ground.
    
    I value expressive freedom and generally bristle against strict rules. But sometimes, I find myself spending way too many mental cycles trying to decide on a name. I wouldn't say it's wasted time to develop an absolutely polished artisanal house style. But if I'm dithering between roughly equivalent options and I feel my enjoyment dropping, it's nice to have a tiebreaker.
    
    (That said, I don't write much Go anymore—so whether the links folks are posting are good tiebreakers, I'll leave that up to others!)
    
    coxley
    
    I've always found Andrew Gerrand's presentations timeless. He has several great ones from early-Go that capture the ethos of the language, or at least what made me fall in love with it at the time.
    
    southclaws
    
    i've never seen a good reason for
    
    If you want to use more than one word in the package name, you should concatenate the words all in lowercase with no separator.
    
    silly nonsense imo, readability matters, i can scan "order_manager" much easier than "abunchofwords"
    
    sure, ideal world you have packages with real short one word names, but in the real world, sometimes you need an "order_manager" and I'm always going to add that underscore in there for everyone's sake as there's zero downside to having it there and only upsides.
    
    pondidum
    
    I think I'll stick to the usual way I and my teams work on a codebase: follow language conventions and try and be consistent.
    
    telemachus
    
    I can't tell what you're responding to. I also can't tell if you think you're disagreeing with the article. Did you actually read it? The whole point is to introduce people to the key language conventions for Go.
    
    pondidum
    
    I did read it, and it felt like a lot of unnecessary rules on things, I suppose its just a more explicit version of what most teams end up with anyway. In general, it feels like these kind of rules are not the best thing to be spending time on.
    
    mxey
    
    And this article is a summary of the language conventions
    
    hjvt
    
    Go: a language so simple, it's naming conventions need a guide.
    
    mdaniel
    
    So, for example, apiKey or APIKey is good, but ApiKey is not
    
    err, don't the good and bad differ only by their visibility? Or is the observation not to make API Keys public? :-D
    
    telemachus
    
    No, the point is this: "acronyms or initialisms (like API, URL or HTTP) should use a consistent case within the identifier." So, apiKey (for something you don't export) or APIKey (for something you do export) rather than ApiKey because you want all the letters in "api" to be all uppercase or all lowercase.
    
    carlana
    
    Because someone dared to submit a story not tagged with vibecoding, I'll talk about something else:
    
    I agree with all these naming conventions and try to follow them. But I don't know what to do with LLMs where they don't follow conventions. Do I just say "hey read this URL before you start coding" for every session? I'm working on using an assistant more and even when I say "don't use grep if you can use go doc" half the time it will use grep anyway. I'm not sure what the right solution is here. Maybe just have a code review step that says to read this and fix the PR at the end. :-/
    
    spc476
    
    In the LLM sandbox, give it a grep that crashes hard, so the LLM can't use it. Also, wrap the go compiler to enforce the naming conventions you want (while cursing Rob Pike for not enforcing it from the start in the go compiler), to again, force the LLM to fix its own mistakes.
    
    Bonus points for vibe coding all this.
    
    carlana
    
    The naming conventions are natural language ones, so I'll have to shell out to an LLM to enforce them. Could vibecode up a git hook tho…