Idiomatic Go (2016)

52 comments

·March 9, 2025

hnlmorg

I’ve worked with people who raised comments like these in PRs and they were a nightmare: always arguing, never listening to anyone but themselves, and generally full of ego. Good developers but often slow to deliver too.

If you’re focused on what character of “GitHub” or “oauth” should capitalised in a variable name, then you really are focusing on the wrong problems of software development.

B-Con

There is value in having local consistency, which is usually achieved through having rules.

The more uniform a code base, the easier it is to breeze around and get stuff done. Naming things is already hard, so having rules around the annoying bits is nice.

rs186

I'm afraid this is a waste of everybody's time.

> Avoid unused method receiver names

That's just "don't create a non-static method if you don't use 'this'" in other languages with classes. Which is not a bad idea, but hardly matters. If someone realizes that it's difficult to add a unit test for the function, they'll fix it themselves. Maybe the real question is: did the code author create a unit test for the function?

(P.S. I never understood why Go uses words like "receiver" and "marshaling" that are rarely used elsewhere)

> Empty string check

Sure, but that's just ordinary code smell, likely due to someone not thinking carefully over the code, which could be easily identified in a code review. If it's never found, it barely matters anyway. Is it really worth bringing this up?

Everything else seems unnecessarily boring, like the number of spaces between sentences. Most people I know write comments like how they write regular English sentences, like in emails. Other than a professor who is near retirement age, I don't know anyone who uses double spaces. It's so rare I don't see any point in mentioning it. And if someone did do this in the code, whether it's their style or by accident, I wouldn't even flag it in the code review. For what? Does anyone benefit from it? It's important to have consistency over fundamental things like tab vs space, but that quickly becomes meaningless bikeshedding.

My advice would be: write code using your common sense. Don't be obsessed with trivial things that don't matter. Use your time elsewhere -- push a new feature, fix a bug, add a unit test, or just relax.

tczMUFlmoNk

> > Avoid unused method receiver names

> That's just "don't create a non-static method if you don't use 'this'" in other languages with classes.

I don't think that's what's meant. It means to write `func (Receiver) Method()` rather than `func (r Receiver) Method()` when you don't use `r`. Sometimes you need this to implement an interface like `error` or `Stringer` and you just don't need instance data.

(I'm no Go apologist but I think "receiver" is a great term. It's clear, it's applies to other languages and paradigms, and it doesn't really have an alternative that I'm aware of.)

layer8

The term “receiver” comes from Smalltalk: http://www.bitsavers.org/pdf/xerox/parc/techReports/SSL-76-6...

tczMUFlmoNk

That makes sense. I just about figured it would. :-)

adastra22

> P.S. I never understood why Go uses words like "receiver" and "marshaling" that are rarely used elsewhere

What else are you familiar with? Those are extremely common terms in the object oriented community.

MooseBurger

Method? Serialize?

atombender

A receiver isn't a method. It's the "self" instance the method is invoked on. It's standard OOP terminology.

I'm with you regarding marshaling, but not because it's not an industry-standard term, it's just that Go misapplies it. Marshaling historically has referred to describing a remote procedure call and its return value; for example, you call "CreateFoo()" with a "CreateRequest", the latter must be marshaled into a payload that the remote call can read. For a network call this requires serializing the data to bytes using some kind of format, but for a local call it could just be a pointer to a data structure. However, historically people have often mixed the two terms. Python's standard library also misuses "marshal" to refer to serialization.

mkl95

> (P.S. I never understood why Go uses words like "receiver" and "marshaling" that are rarely used elsewhere)

Not sure about receiver, but marshaling has been part of Python's lingo for ages.

layer8

“Marshaling” became pretty ubiquitous as a term in the 1990s with CORBA and Microsoft OLE/COM.

cratermoon

The term 'receiver' has a long and distinguished history. Alan Kay used it, Smalltalk used the word almost exclusively. If Zoomers don't know their computer science history that's on them.

> That's just "don't create a non-static method if you don't use 'this'" in other languages with classes

Go doesn't have static methods. Regardless if you name the receiver, you have to provide an instance of the type to all methods. Maybe you should check your own knowledge before criticizing others

mjburgess

> When reviewing Go code

This article reads as a parody of the worst sort of code review. This seems to be a person who sees themselves as little more than a regex engine.

Were I writing a go codebase in the UK, all spellings would be UK -- because of how absurd it would be to retrain the staff to split their brain on a trivial issue of this kind.

Likewise plurals do not matter, -- double spacing in comment sentences? I cannot imagine comment whitespacing being on the radar of any person one would wish to have as a team mate.

Joker_vD

> Were I writing a go codebase in the UK, all spellings would be UK.

What about if you were in Australia? Germany? Poland? Bulgaria? China?

> how absurd it would be to retrain the staff to split their brain on a trivial issue of this kind.

I've seen this argument used to argue that all the spellings in source code should be US English, always and everywhere. In my opinion, this (being able to use the same argument to argue both for and against the same issue) invalidates the argument entirely.

jrockway

Being consistent is the key. When you open up a codebase worked on by 50 people, it's nice when you can't tell who wrote it because of the spelling or whatever. Everyone on the team can see it, think "this looks like I wrote it", and work on it accordingly. That's a good thing.

Mogzol

The link in the "Error variable naming" section seems to directly contradict what the section says.

The link (https://go.dev/talks/2014/names.slide#14) says:

  Error values should be of the form ErrFoo:
  
  var ErrFormat = errors.New("image: unknown format")

But the page says:

  // But if you want to give it a longer name, use "somethingError".
  var specificError error
  result, specificError = doSpecificThing()

And also says:

  Don't do this:
  [...]
  var errSpecific error
  result, errSpecific = doSpecificThing()

So should error variables written like `errSpecific` or `specificError`? The go wiki says they should be written starting with `err`: https://go.dev/wiki/Errors#naming

danw1979

Pedantic Go more like…

“oAuth is not pretty” but “oauth” is ?

We’ve all had PRs reviewed by people like this and we know where it leads.

dlahoda

where it leads?

null

[deleted]

stevebmark

Idiomatic Go is using shortened variable names, not what's in this article. I thought that was common knowledge and part of the Go ethos? I also wouldn't consider grammar in comments part of the language idioms? This is an unusual and very light take on Golang language idioms.

prisenco

My understanding is that shortened variable names are recommended for small, tight contexts (loops, short functions) but not generally.

cube2222

That and conventionally standard names, like r for request/reader, w for writer, etc.

Agreed. Functions shouldn’t be full of short non-descriptly named variables.

The longer the lifetime/scope of a variable, and the more variables there are, the more descriptive the names should be.

GauntletWizard

These are dang short compared to Java's FooBarBazBeanFactoryFuncClassImpl. The point you may be responding to is that "Short variable names" are themselves contextual. If you're doing a simple loop:

  for i := range personlist {
    person := personlist[i]
    ...
  }

Is more readable than

  for personNum := range personlist {
    person := personlist[personNum]
    ...
  }

because it makes clear that the i is basically irrelevant. The latter isn't bad style if you're three loops deep, because i, j, k is a bit harder to keep track of which is which.

callc

I used Golang in a medium and large project. To anyone learning or thinking about learning Go, try it and ignore the online opinions.

I say this as someone who is simultaneously impressed by some parts of it, and gobsmacked at other parts.

Just ignore the dogmatic Gopher priests.

dlahoda

why ignorance is good?

crackrook

I'm not angry about it but the fact that Go uses capitalization for access control is just so silly to me. Like something a child might design when figuring out how to hide secrets in a note.

TechDebtDevin

In case no one has mentioned it, Learning Go, an Idiomatic approach to real world programming, by Jon Bodner is my favorite Go related book and one of my favorite programming books in general.

https://books.google.com/books/about/Learning_Go.html?id=vjA...

gnabgib

(2016) Based on the comment/voting entries, first submitted here in 2018.. I wonder if the author feels the same 9 years later.

liampulles

Here's the idiomatic Go style guide: accept whatever go format outputs. The fact that go formats code by default is one of the best things about the language. The whole point is that spending time either correcting whitespace (or even worse, arguing about how much whitespace to put) is an absolute waste of time and a comradery killer.

koakuma-chan

It's the same language that "marshals" and "unmarshals" JSON and "dials" sockets.

tptacek

Dial is a Plan9-ism and it's hard to argue that it isn't a lot better than the BSD sockets interface.

HN

Idiomatic Go (2016)

Idiomatic Go (2016)