Reputation: 5529
I'm trying to learn Go, using Visual Studio Code, and I guess it's using a Go linter. I created this struct to map a JSON object into.
type someAPI struct {
ApiEndpoint string `json:"apiEndpoint"`
ApiVersion string `json:"apiVersion"`
...
}
And I get these warnings...
struct field ApiEndpoint should be APIEndpoint
struct field ApiVersion should be APIVersion
I did some Googling and I can not find any requirements for struct field names regarding this. The most I've found is that if you want to make a field public you have to capitalize it.
So why is this linter warning me about these names?
I did some testing by changing Api
to Abc
and the linter didn't warn me to change it to "ABC". So I have to assume it's checking for names that start with "Api".
What are Go conventions for field names? Or in other words, are there other conventions I should know about?
Upvotes: 25
Views: 42855
Reputation: 5002
For most cases the naming convention in Go is just to use camel case and start with upper case if it's a public field and lower case if it's not. But in words that are acronyms like API or URL they are written in full upper case eg. func ProxyURL(fixedURL *url.URL)
on the http package.
EDIT: I searched for a little bit more and there are guidelines for acronyms on the Go Code Review Comments. It talks about acronyms in the Initialisms section:
Words in names that are initialisms or acronyms (e.g. "URL" or "NATO") have a consistent case. For example, "URL" should appear as "URL" or "url" (as in "urlPony", or "URLPony"), never as "Url". As an example: ServeHTTP not ServeHttp. For identifiers with multiple initialized "words", use for example "xmlHTTPRequest" or "XMLHTTPRequest".
This rule also applies to "ID" when it is short for "identifier", so write "appID" instead of "appId".
So the rule for acronyms is that they should have constant case. In your case because they have to start with uppercase "A" you should write them as "API".
Also this is just my personal opinion and I know that the code in the example might not be the exact code you are using but if it is, I think it's a bad practice to include the struct name on the field names. You are doing api.APIField
but api.Field
is easier to read and if you know the object is an API then there is not doubt that the Field belongs to an API.
Upvotes: 44
Reputation: 2827
Like mentioned here in your question and in @topo's answer, the convention for variable an function naming is Camel Case (mixed caps). If the name starts with an upper case letter the variable/function can be exported.
Packages are always lower case.
Interfaces should end with -er
You can read more in the effective go naming session
Golint on the other hand, goes beyond Go convention for naming. There are a few rules for words and in your case you are hitting one of the rules. You can see the full list here: https://github.com/golang/lint/blob/master/lint.go#L751
Upvotes: 4