Struct Naming Convention

Question

I have a few structs in a package that make a simple finance API call, one implements the request to the API, one stores the response.

I'm wondering if it's appropriate to just name the structs "Request" and "Response" respectively, or should I prefix them with the subject/package- like "FinanceRequest" and "FinanceResponse"? Or would that make external calls redundant by using finance.FinanceRequest (finance word used twice)?

Looking for thoughts on the matter (golang convention/preference)...

Samples:

package finance

type Request struct {
//...
}

type Response struct {
//...
} 

func DoSomething(r *Request) (*Response, error) {
//...
}

or

package finance

type FinanceRequest struct {
//...
}

type FinanceResponse struct {
//...
} 

func DoSomething(r *FinanceRequest) (*FinanceResponse, error) {
//...
}

Answer 1

The convention is to use Request and Response. Here's what Effective Go has to say:

The importer of a package will use the name to refer to its contents, so exported names in the package can use that fact to avoid stutter. (Don't use the import . notation, which can simplify tests that must run outside the package they are testing, but should otherwise be avoided.) For instance, the buffered reader type in the bufio package is called Reader, not BufReader, because users see it as bufio.Reader, which is a clear, concise name. Moreover, because imported entities are always addressed with their package name, bufio.Reader does not conflict with io.Reader.

The golint tool will complain about the names FinanceRequest and FinanceResponse.