I was thinking about golang naming syntax, as we all know that upper or lower case initials change the visibility of functions and variables.
As there is no strict standard for golang, I often use snake case. It is a personal preference. I used to like camel/pascal case when I programmed in Java, but back there upper or lower case initials were strictly defined. If I would choose to use camel case in Go I’d often write a “get” function as GetStuff() so that it is public, as opposed to the getStuff() that would have been implemented in Java. Personally, GetStuff() kinda hurt my eyes.
In Python we could effortlessly implement a public function get_stuff() or a private _get_stuff(), which is not pretty, but it is ok.
Getting to the point: in Golang, if I choose to use snake case, then a private function would look like get_stuff(). Consequently, a public one would be named Get_stuff(), which looks like a snake with a large head. It’s got me thinking: shouldn’t we call this one a “cobra case”?
Idk how useful this topic would be, but “cobra case” got me in a good mood .
There is no official standard afaik, but idiomatic code uses CamelCase (look at the standard library for instance).
You can do whatever you want in your code (no one will stop you), but I tend to avoid packages that deviate, for no other reason than the author likely doesn’t know the standard library well and therefore probably not golang well either.
But personllay I have no additional issue with Golangs way of doing it.
I often do named imports that will be in this case:
package.GetStuff()
And what I do for myself is structs with a T at the end.
so instead of type Stuff struct {} I do StuffT struct and I follow the same in typescript frontend. Thus I always know what is the type definition and what an actual struct.
Coming from experience with a lot of other languages, I do find the Go convention of initial-upper-for-public a bit too cute. I, too, am mildly annoyed at the visual impression of names I have to create and use.
Go could have a ‘public’ and ‘private’ qualifier that would only complicate the (parsing of the) single place a name is declared. It would not complicate the job of the developer of the package, who already has to make the visibility decision.
When consuming imported names, all the visible names currently have that initial upper case character, <package>.<upper><rest-of-name>. That’s just redundant effort for all the consumers.
Why not extend Go’s laudable freedom from naming constraints to allow public names to have an initial lower case name as well?
.