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?
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.