[Go] Naming

Reference:
https://talks.golang.org/2014/names.slide



Name it in:

• MixedCase.
• Consistent (easy to guess),
• Short (easy to type),
• Accurate (easy to understand).

The greater the distance between a name's declaration and its uses,
the longer the name should be.
i.e using single char naming for 'for' loop is just fine.



Prefer i to index.
Prefer r to reader.
Prefer b to buffer.



Function parameters are like local variables,
but they also serve as documentation.
e.g Where the types are descriptive, they should be short:

func AfterFunc(d Duration, f func()) *Timer
func Escape(w io.Writer, s []byte)

Where the types are more ambiguous, the names may provide documentation:

func Unix(sec, nsec int64) Time
func HasPrefix(s, prefix []byte) bool

Return values on exported functions should only be named for
documentation purposes.
These are good examples of named return values:

func Copy(dst Writer, src Reader) (written int64, err error)
func ScanBytes(data []byte, atEOF bool) (advance int, token []byte, err error)

Receivers are a special kind of argument.
By convention, they are one or two characters that reflect the receiver type,
because they typically appear on almost every line.
Receiver names should be consistent across a type's methods.
(Don't use r in one method and rdr in another.)



Exported names are qualified by their package names.
Remember this when naming exported
variables, constants, functions, and types.
That's why we have bytes.Buffer and strings.Reader,
not bytes.ByteBuffer and strings.StringReader.




Interfaces that specify just one method are usually just that function
name with 'er' appended to it.
Sometimes the result isn't correct English, but we do it anyway.
When an interface includes multiple methods,
choose a name that accurately describes its purpose
(examples: net.Conn, http.ResponseWriter, io.ReadWriter).




Error types should be of the form FooError:

type ExitError struct {
    ...
}

Error values should be of the form ErrFoo:

var ErrFormat = errors.New("image: unknown format")

Choose package names that lend meaning to the names they export.
Steer clear of util, common, and the like.



The last component of a package path should be the same as the package name.
Avoid stutter in repository and package paths.
Avoid upper case letters (not all file systems are case sensitive).
For libraries, it often works to put the package code in the repo root:

"github.com/golang/oauth2" // package oauth2