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?
In Golang, any variable (or a function) with an identifier starting with an upper-case letter (example, CamelCase) is made public (accessible) to all other packages in your program, whereas those starting with a lower-case letter (example, camelCase) is not accessible to any package except the one it is being declared ...
The convention in Go is to use MixedCaps or mixedCaps (simply camelCase) rather than underscores to write multi-word names. If an identifier needs to be visible outside the package, its first character should be uppercase. If you don't have the intention to use it in another package, you can safely stick to mixedCaps .
Naming Conventions for Golang Functions. A name must begin with a letter, and can have any number of additional letters and numbers. A function name cannot start with a number. A function name cannot contain spaces. If the functions with names that start with an uppercase letter will be exported to other packages.
Declaring and initializing an Array of Structs We simply declare an array with the type of that struct. 2. Inserting values in an Array of Structs Use append function which returns the slice after insertion. Or, we can simply use indexing like this. This is how we can use structs in Go for various purposes.
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.
Code formatting and naming convention tools in Golang The formatting of code shows the way code is formatted in a file. It points out to the way, how code is designed and how carriage returns used in writing. Go does not require special rules around the code formatting, but have a standard that is generally used and accepted in the community.
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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With