Go Style: Difference between revisions

From NovaOrdis Knowledge Base
Jump to navigation Jump to search
Line 58: Line 58:
=Idiomatic Error Handling=
=Idiomatic Error Handling=
{{Internal|Go_Language_Error_Handling#Idiomatic_Error_Handling|Idiomatic Error Handling}}
{{Internal|Go_Language_Error_Handling#Idiomatic_Error_Handling|Idiomatic Error Handling}}
=Getters and Setters=
{{External|https://go.dev/doc/effective_go#Getters}}
Go does not provide automatic support for getters and setters, but there is nothing wrong with programming getters and setters yourself.
These are the conventions around getters and setters, documented in [https://go.dev/doc/effective_go#Getters effective_go]:
* The field should be [[Go_Packages#Unexported_Members|unexported]] (lower-case name). Example: <code>name</code>.
* The getter method should have the same name as the field, except the for the first character, which is upper-case, making it exported. Example: <code>Name()</code>. It is neither idiomatic, not necessary to put "Get" in the getter's name. The method '''should not''' be called <code>GetName()</code>.
* The setter method should be called <code>SetOwner()</code>.
<syntaxhighlight lang='go'>
type SomeStruct struct {
name string // unexported
}
// Name is the getter method, exported. Must not be called GetName()
func (s *SomeStruct) Name() string {
return s.name
}
// SetName is the setter method, exported
func (s *SomeStruct) SetName(name string) {
s.name = name
}
</syntaxhighlight>

Revision as of 00:39, 4 July 2024

External

Internal

Overview

The Go standard library is a good source of code examples, comments and style.

Line Length

Go has no line length limit. However, if the line feels too long, wrap it and indent it with an extra tab.

Naming

https://google.github.io/styleguide/go/guide#mixedcaps

Naming is one of the most important aspects of Go development. Writing idiomatic Go requires understanding of its core naming principles.

Identifiers

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. This is a reason to try to make the package name and the feature name work together.

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.

Long names do not automatically make things more readable. A helpful doc comment can often be more valuable than an extra long name.

Other naming conventions:

Integrate this:

Comments

Go Language | Comments

Idiomatic Error Handling

Idiomatic Error Handling
Retrieved from "https://kb.novaordis.com/index.php?title=Go_Style&oldid=111247"