Live data from Hacker News

Go Style

google.github.io

211–212 of 212 posts

Re: Go Style

#211
post #25

Earlier quoted context omitted.

Indeed, this is one Go convention that I strongly dislike. Java did have that approach once (HTMLDOMURIReference, XMLIDREF and the likes) but they learned their lesson. And what's the basis of capitalizing D in ID?

I also dislike "ID" vs "id" (as short for "identity"), but there is some case for it. The below are from Webster's Third New International Dictionary Unabridged. First, the case for "id": id abbreviation 1 [Latin idem] the same Now for "ID" ID noun, plural ID's or IDs [REVISED] [identification] 1 a : documentation bearing identifying information

And "Id" is that Freudian thang, not quite the same as identification.

Re: Go Style

#212
post #95

Earlier quoted context omitted.

I mostly avoid getters/setters in Go code, unless I have a lot of functions all related to the same thing similarly named. It's the return type that denotes the return. It's already in the function signature. That advice is a consequence of Go expecting function signatures to be read and understood. That's not the right choice for all programming languages, but for Go it works.

I mean, you can't get around database CRUDs. I'm not talking about setting a private variable and getting or setting it (that doesn't seem like idiomatic Go at all), but using the logic described above, you can't know whether a method with a noun-based name is a Read or a Create.

Shouldn't a Create have the form NewBlah ? Incidentally warning that there is a memory allocation.
Post reply on HN