Go Style

External

• https://google.github.io/styleguide/go/
• https://go.dev/doc/effective_go
• https://github.com/golang/go/wiki/CodeReviewComments

Internal

• Go Engineering
• Go Source Code Formatting
• gofmt

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.

Comments

Go Language | Comments

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. The following rules apply to constant and variable identifiers, function names, type names, like struct or interface names.

Names have a semantic effect. The visibility of a name outside a package is determined whether its first character is upper case. See:

Exported Identifiers

Go style recommends camel-case (mixed-case) for identifiers, rather than snake-case (underscore) to write multi-word names. Use SomeVariable or someVariable, depending on whether the variable is visible outside the package or not. Do not use snake case some_variable. Every exported name should be documented with a comment.

Names, and in special variable names, should be short rather than long. Long names do not automatically make things more readable. A helpful doc comment can often be more valuable than an extra long name.

Acronyms should have a consistent case. URL or url is correct, Url is not. Prefer all-capital acronyms, if it makes sense (URL).

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.

When a feature 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.

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

Integrate this:

• https://go.dev/talks/2014/names.slide#1
• https://golang.org/doc/effective_go.html#names
• https://blog.golang.org/package-names
• https://rakyll.org/style-packages/

---

END

Where more specific rules apply to a particular kind of name, those rules are documented in a dedicated style section:

Constants

Constants Naming

Variables

Variables Naming

Packages

Package Names

Interfaces

Interfaces

Source Files

Source File Naming

Functions

Function Naming

Getters and Setters

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 naming the getters and setters, documented in effective_go:

• The field should be unexported (lower-case name). Example: name.
• 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: Name(). It is neither idiomatic, not necessary to put "Get" in the getter's name. The method should not be called GetName().
• The setter method should be called SetOwner().

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
}

Idiomatic Error Handling

Idiomatic Error Handling