Naming conventions for Go language learning skills

preface

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

Go's functions, variables, constants, custom types, and packages (Package) are named as follows:

1) The first character can be any Unicode character or underscore

2) The remaining characters can be Unicode characters, underscores, and Numbers

3) Unlimited character length

Go has only 25 keywords

break default func interface select
case defer go map struct
chan else goto package switch
const fallthrough if range type
continue for import return var

Excellent naming

Good naming should be consistent, short, and accurate. 1 consistency means that the name of the same meaning should be 1 in different circumstances, such as dependencies, rather than depend in one method and rely in the other. When the name is too long, readers may pay more attention to the name itself and neglect the real logical content. The so-called accurate, is named meaning, easy to understand

The first lesson

The farther the declared location is from the used location, the longer the name should be.

Camel nomenclature

The Go language should use MixedCase (Do not use names_with_underscores) Initials should be capitalized, e.g. ServeHTTP, sceneID, CIDRProcessor.

A local variable

Local variables should be as small as possible, such as buf for buffer and i for index Long functions can have many variables, so use 1 long names when appropriate. But writing such a long function usually means that the code needs to be refactored! The & # 128581; The & # 127995; The & # 8205;

parameter

The arguments to functions are similar to local variables, but they also have documentation by default

When the parameter type is descriptive, the parameter name should be as short as possible:

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

When the parameter type is fuzzy, the parameter name should be a document:

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

The return value

In Go, the return value can be named as a special parameter.

In particular, in externally visible functions, the name of the return value should serve as a document reference.

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

Method Receiver (Receiver)

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

By convention, because the method receiver is often present inside a function, it often USES 1 and 2 letters to identify the type of the method receiver.

func (b *Buffer) Read(p []byte) (n 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 remain consistent with 1 in different methods of the same type, which is also a requirement for consistency as described above.

Export package level naming

The export name is usually used after the package name

So, when exporting variables, constants, functions, and types,

Do not write the meaning of the package name again

Better name

bytes.Buffer strings.Reader

Stupid names

bytes.ByteBuffer strings.StringReader

The interface type

Interface types that contain only 1 method usually have the function name followed by the er suffix as the name

type Reader interface {
  Read(p []byte) (n int, err error)
}

Sometimes it can lead to broken English, but forget about it. Just be able to understand

type Execer interface {
  Exec(p []byte) (n int, err error)
}

Sometimes the order of English words can be adjusted appropriately to increase readability:

type ByteReader interface {
  ReadByte(p []byte) (n int, err error)
}

When an interface contains multiple methods, choose a name that accurately describes the purpose of the interface, such as ES110en.Conn, http/ResponseWriter

The naming of Error

The Error type should be written as FooError

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

0

The form of the Error variable coroutine ErrFoo

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

1

The naming of the package

It should be relevant to the content of the code it exports, and avoid broad names like util and common

The introduction of the path

The last word of the package path should be the package name 1

The package path should be as concise as possible

Remember to place the main code of the library 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)

The standard library

Many of the examples above are from the standard library

Much of the library can be used as a reference
Check out the standard library for inspiration

But remember:

When authors write standard libraries, they themselves are in the process of learning.
The author is right most of the time, but occasionally he makes a few mistakes

conclusion

reference

What's in a name? - Andrew Gerrand