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.
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`.
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.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
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 anErrprefix.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.
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.Package Names (Go Blog)
Use short names (
time,list, andhttp).Don't abbreviate if it causes ambiguity.
Avoid repition (stutter).
Use New as an entry point for client code.
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.