Names #33

New Issue

jeff · 2021-05-30T21:50:00Z

jeff commented

2021-05-30 21:50:00 +00:00

What's in a name?

Readability is the defining quality of good code. A good name is consistent, short, and accurate.

The greater the distance between a name's declaration and its uses,
the longer the name should be.

Use MixedCase (no snake_case).

Capitalize acronyms.

Avoid redundant names (runeCount in a func called RuneCount).

The perceived need for a longer name may be an indication of a need to refactor.

Names may serve as documentation in func signatures.

Avoid named return values. They may add documentation in some places.

Keep method receivers less than 3 characters. Use a consistent name across the type's methods.

Do not stutter on exported names (strings.StringReader).

Single method interfaces should be the method name with 'er' appended. If there are multiple methods, be sure to choose a name that is accurate.

Error types should have the suffix Error. Error values should have an Err prefix.

Avoid generic package names like util, common, pkg, etc.

Keep import names lowercase, and the package name as the final part of the import path. Avoid stutter ("code.google.com/p/goauth2/oauth2").

The standard library is a good place to find good ways to write Go code, but not all of it is.

[What's in a name?](https://talks.golang.org/2014/names.slide#2) Readability is the defining quality of good code. A good name is consistent, short, and accurate. The greater the distance between a name's declaration and its uses, the longer the name should be. Use MixedCase (no snake_case). Capitalize acronyms. Avoid redundant names (runeCount in a func called RuneCount). The perceived need for a longer name may be an indication of a need to refactor. Names may serve as documentation in func signatures. Avoid named return values. They may add documentation in some places. Keep method receivers less than 3 characters. Use a consistent name across the type's methods. Do not stutter on exported names (strings.StringReader). Single method interfaces should be the method name with 'er' appended. If there are multiple methods, be sure to choose a name that is accurate. Error types should have the suffix `Error`. Error values should have an `Err` prefix. Avoid generic package names like `util`, `common`, `pkg`, etc. Keep import names lowercase, and the package name as the final part of the import path. Avoid stutter (`"code.google.com/p/goauth2/oauth2"`). The standard library is a good place to find good ways to write Go code, but not all of it is.

jeff commented

2021-05-30 21:59:51 +00:00

Effective Go: Names

Short, concise, and evocative.

Keep package names short, preferably one word.

The package name should be the basename of the directory it's in.

Don't prefix Getters with Get.

[Effective Go: Names](https://golang.org/doc/effective_go#names) Short, concise, and evocative. Keep package names short, preferably one word. The package name should be the basename of the directory it's in. Don't prefix Getters with `Get`.

jeff commented

2021-05-30 22:09:03 +00:00

Package Names (Go Blog)

Use short names (time, list, and http).

Don't abbreviate if it causes ambiguity.

Avoid repition (stutter).

Use New as an entry point for client code.

If you cannot come up with a package name that's a meaningful prefix for the package's contents, the package abstraction boundary may be wrong. Write code that uses your package as a client would, and restructure your packages if the result seems poor. This approach will yield packages that are easier for clients to understand and for the package developers to maintain.

The last element of the import path is the package name.

Meaningless (util, common, pkg) names are bad; they do not give any inidication of the package's contents.

[Package Names (Go Blog)](https://blog.golang.org/package-names) Use short names (`time`, `list`, and `http`). Don't abbreviate if it causes ambiguity. Avoid repition (stutter). Use New as an entry point for client code. > If you cannot come up with a package name that's a meaningful prefix for the package's contents, the package abstraction boundary may be wrong. Write code that uses your package as a client would, and restructure your packages if the result seems poor. This approach will yield packages that are easier for clients to understand and for the package developers to maintain. The last element of the import path is the package name. Meaningless (`util`, `common`, `pkg`) names are bad; they do not give any inidication of the package's contents.

Sign in to join this conversation.