Golang conventions: Difference between revisions
From wikinotes
(→Naming) |
(→Naming) |
||
(6 intermediate revisions by the same user not shown) | |||
Line 1: | Line 1: | ||
= Naming = | = Naming = | ||
<blockquote> | <blockquote> | ||
== Modules == | |||
<blockquote> | |||
Modules can be multiple words, but should be separated by dashes. | |||
</blockquote><!-- Modules --> | |||
== Packages == | |||
<blockquote> | |||
Packages are snake-case if required. But prefer that they are not. | |||
</blockquote><!-- Packages --> | |||
== Brevity == | == Brevity == | ||
<blockquote> | <blockquote> | ||
Go prefers short names, with good doc comments for both functions and packages.<br> | Go prefers short names, with good doc comments for both functions and packages.<br> | ||
Imported package names are typed every time a symbol is used. | Imported package names are typed every time a symbol is used. | ||
Go also prefers you drop the <code>get</code> prefix of getters. | |||
</blockquote><!-- Brevity --> | </blockquote><!-- Brevity --> | ||
== Casing == | == Casing == | ||
<blockquote> | <blockquote> | ||
=== Functions === | |||
<syntaxhighlight lang="go"> | <syntaxhighlight lang="go"> | ||
func DoThing() { ... } // exported functions are PascalCase | func DoThing() { ... } // exported functions are PascalCase | ||
func doThing() { ... } // regular functions are camelCase | func doThing() { ... } // regular functions are camelCase | ||
</syntaxhighlight> | |||
=== Variables === | |||
<syntaxhighlight lang="go"> | |||
var URL string = "https://example.com" // acronyms are uppercase | |||
var catName string = "foo" // regular vars are camelCase | |||
var DogName string = "foo" // constants in pascal-case are exported | |||
</syntaxhighlight> | </syntaxhighlight> | ||
</blockquote><!-- Casing --> | </blockquote><!-- Casing --> | ||
Line 26: | Line 47: | ||
</syntaxhighlight> | </syntaxhighlight> | ||
</blockquote><!-- Interfaces --> | </blockquote><!-- Interfaces --> | ||
== Tests == | |||
<blockquote> | |||
* Tests are kept alongside the code, and have the suffix <code>_test.go</code> | |||
* Tests themselves are functions, with a prefix of <code>Test</code> followed by the name of the function being tested | |||
* You may create subtests, evaluated by a top-level test, that can share setup/teardown code. | |||
</blockquote><!-- Tests --> | |||
</blockquote><!-- Naming --> | </blockquote><!-- Naming --> | ||
= Spacing = | = Spacing = | ||
<blockquote> | <blockquote> | ||
Golang prefers the use of tabs, not spaces. Adjust your tabwidth if you like. | |||
</blockquote><!-- Spacing --> | </blockquote><!-- Spacing --> | ||
Latest revision as of 04:55, 26 June 2022
Naming
Modules
Modules can be multiple words, but should be separated by dashes.
Packages
Packages are snake-case if required. But prefer that they are not.
Brevity
Go prefers short names, with good doc comments for both functions and packages.
Imported package names are typed every time a symbol is used.Go also prefers you drop the
get
prefix of getters.Casing
Functions
func DoThing() { ... } // exported functions are PascalCase func doThing() { ... } // regular functions are camelCaseVariables
var URL string = "https://example.com" // acronyms are uppercase var catName string = "foo" // regular vars are camelCase var DogName string = "foo" // constants in pascal-case are exportedInterfaces
// interfaces should end in 'er' (or similar) Writer, Reader, Formatter, Notifier, Flusher, Stringer // implementations of interfaces should drop the 'er' Write, Read, Format, Notify, Flush, StringTests
- Tests are kept alongside the code, and have the suffix
_test.go
- Tests themselves are functions, with a prefix of
Test
followed by the name of the function being tested- You may create subtests, evaluated by a top-level test, that can share setup/teardown code.
Spacing
Golang prefers the use of tabs, not spaces. Adjust your tabwidth if you like.
Syntax
Semicolons
Go uses semicolons as line-endings, but prefers that the semicolon is implied automatically.