Go Style: Difference between revisions
(→Naming) |
(→Naming) |
||
Line 16: | Line 16: | ||
[[Go_Language#Identifiers_.28Names.29|Identifiers]] should use camel case: <code>SomeColor</code> or <code>someColor</code>, depending on whether they are visible outside the package or not. This is how [[Go_Packages#Packages_as_Encapsulation_Mechanism|package encapsulation]] works. | [[Go_Language#Identifiers_.28Names.29|Identifiers]] should use camel case: <code>SomeColor</code> or <code>someColor</code>, depending on whether they are visible outside the package or not. This is how [[Go_Packages#Packages_as_Encapsulation_Mechanism|package encapsulation]] works. | ||
Do not use snake case <code>some_color</code>. Every exported name should be documented with a comment, following [[Go_Language#Comments|idiomatic comment conventions]]. | Do not use snake case <code>some_color</code>. | ||
Every exported name should be documented with a comment, following [[Go_Language#Comments|idiomatic comment conventions]]. | |||
Acronyms should have a consistent case. <code>URL</code> or <code>url</code> is correct, <code>Url</code> is not. | Acronyms should have a consistent case. <code>URL</code> or <code>url</code> is correct, <code>Url</code> is not. |
Revision as of 00:39, 7 September 2023
External
- https://google.github.io/styleguide/go/
- https://go.dev/doc/effective_go
- https://github.com/golang/go/wiki/CodeReviewComments
Internal
Overview
The Go standard library is a good source of code examples, comments and style.
Naming
Naming is one of the most important aspects of Go development. Writing idiomatic Go requires understanding of its core naming principles.
Identifiers should use camel case: SomeColor
or someColor
, depending on whether they are visible outside the package or not. This is how package encapsulation works.
Do not use snake case some_color
.
Every exported name should be documented with a comment, following idiomatic comment conventions.
Acronyms should have a consistent case. URL
or url
is correct, Url
is not.
When a variable, struct or interface is imported from another package, its name includes the package name or alias: mypackage.MyVar
.
Use name abbreviations only if they are widely used (example: fmt
).
Avoid name collisions, when possible. If you introduce a set of string functions, avoid calling the package strings
because a package with the same name exists in the standard library already.
Other naming conventions:
- Idiomatic Package Conventions
- Idiomatic Variable Naming Conventions
- Idiomatic Function Naming Conventions
- Idiomatic Struct Naming Conventions
- Idiomatic Interface Conventions