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.
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.
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.
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!)
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.
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.
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.
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.
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.
telemachus | 21 hours ago
Some other links on naming conventions and rules in Go.
selforthisfor receiver names in Go)michiel | 21 hours ago
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 | 20 hours ago
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.
Really? I thought naming was one of the two famous problems in computer science.
icholy | 20 hours ago
Found the guy who uses snake_case in Go.
ale | 10 hours ago
Forcing style rules is classic webdev pampering though
icholy | 4 hours ago
When I write papers, I use different fonts on every page like a real man.
ale | an hour ago
You don’t write paper be honest with yourself
aoeu | an hour ago
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 | 20 hours ago
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 | 6 hours ago
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 | 6 hours ago
i've never seen a good reason for
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 | 21 hours ago
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 | 20 hours ago
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 | 10 hours ago
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 | 7 hours ago
And this article is a summary of the language conventions
hjvt | 6 hours ago
Go: a language so simple, it's naming conventions need a guide.
mdaniel | 4 hours ago
err, don't the good and bad differ only by their visibility? Or is the observation not to make API Keys public? :-D
telemachus | an hour ago
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) orAPIKey(for something you do export) rather thanApiKeybecause you want all the letters in "api" to be all uppercase or all lowercase.