Go Technical Second naming specification

This is a creation in Article, where the information may have evolved or changed.

This article focuses on the naming conventions of the go language.
Good code must be readable, and the key to readability is the naming style.

Original link: http://zablog.me/2017/09/08/go_tricks_and_tips_2/

Excellent naming

A good name should be consistent, short, and precise.
The so-called consistent, that is, the same meaning in different contexts under the naming should be consistent, such as dependency, not in one method named Depend, another method named rely.
The so-called short, needless to say, when the name is too long, the reader may be more concerned about the naming itself, and ignore the real logical content.
The so-called precision, is the name of the express, easy to understand

First piece of experience

The farther you declare the location and the location you use, the longer the name should be.

Camel name Law

The go language should use Mixedcase
(Do not use names_with_underscores)
Acronyms should be capitalized, for example, ServeHTTP sceneID CIDRProcessor .

Local variables

Local variables should be as short as possible, such as using buf buffer a reference, using a i referenceindex
There may be a lot of variables in a very long function, so you can use some long names appropriately.
But writing such a long function usually means that the code needs to be refactored!??

Parameters

The parameters of the function are similar to local variables, but they also have the functionality of the document by default
When the parameter type is descriptive, the argument name should be as short as possible:

123	func Afterfunc func()) *TimerfuncEscape(w io. Writer, S []byte)

Parameter names should have the functionality of the document when the argument type is ambiguous:

123	func Unix Int64) Time funchasprefix(s, prefix []byte)bool

return value

In the Go language, the return value can be defined as a name, which can be used as a special parameter.
It is particularly important that in externally visible functions, the name of the returned value should be available as a document reference.

12345

func Copy (DST Writer, src Reader) Int64, err error) funcscanbytes(data []bytebool)int , token []byte, err Error)

Method Recipient (receiver)

The method receiver is also a special parameter. There is no obvious object-oriented concept in the Go language, and it is possible to define method recipients of methods to implement the concept of object-like methods.

By convention, because the method receiver often appears inside a function, it often uses one or two letters to identify the type of the receiver of the method.

123456

func (b *buffer) Read (p []byte) int, err error) func(sh serverhandler)servehttp(rw responsewriter, req * Request)func(R Rectangle)Size() Point

It is important to note that the name of the method recipient should be consistent across different methods of the same type, which is the requirement for consistency as described earlier.

Export package-level naming

When the export name is used, it is usually placed after the package name
So, when you export variables, constants, functions, and types,
Don't write the meaning of the package name again.

A better name.
bytes.Bufferstrings.Reader

More stupid names.
bytes.ByteBufferstrings.StringReader

Interface type

An interface type that contains only one method is usually named with the function name plus the er suffix

1234	type Interface { Read (p []byteint, err Error)}

Sometimes it can lead to crappy English, but leave him alone, you can read it.

123	type Interface { Exec (p []byteint, err Error)}

Sometimes you can adjust the order of English words appropriately, and increase readability:

123	type Interface { readbyte (p []byteint, err Error)}

When the interface contains multiple methods, it is still to choose a name that can accurately describe the purpose of the interface, for example net.Conn ,http/ResponseWriter

Name of error

The error type should be written in fooerror form

123	type struct {....}

The form of the error variable co-errfoo

1	var errformat = errors. New ("Unknown format")

Name of the package

Should be related to the content of its exported code, avoid util , common this broad naming

Introduction path

The last word of the package path should be the same as the package name

The package path should be as concise as possible

Remember to put the library's main code directly in the root directory of the code base

Avoid using any uppercase letters in the package path (not all file systems are case-sensitive)

Standard library

Many of these examples are from the standard library.

Many of the contents of the standard library can be used as a reference
Take a look at the standard library and find inspiration.

But remember:

When authors write standard libraries, they themselves are in the process of learning.
In most cases the author is right, but occasionally he makes some mistakes.

Reference documents

1. What's in a name? -Andrew Gerrand