Source: https://www.youtube.com/watch?v=iiIL3LbAFWk
Summary: Looks at how we can think about laying go code out as if it was a story
1package name
2imports ()
3initialisation
4type definitions
5func involving type
6type definition
7func involving type
"Idiomatic Go designs horizontal packages, which can be looked at as independent short stories"
Character is the thing what is the character going to do
world.Noun.Verb
accounts.File.Write
func (t *theThing) Reads(book *Book) (knowledge, err) {}
func (t *theThing) Write(book *Book, txt string) (documentation, err) {}
Function definitions in go can be read as clear first sentences in a paragraph
1func (t *theThing) takesAction (with String) resultsIn {}
Name of a method's receiver should be a reflection of its identity; often one or two letter abbreviations of its type suffices.
You do not need to repeat the characters name in their story.
Single Use variables fragment a paragraph "if you define a variable, often at the top of your function, and you use it underneath, you are often making two different sentences"
1t := time.Now()
2conf, err := c.Query(t)
which reads as
The time is Sept 27th
We had Gophercon at the time.
this means holding more context in memory as you read.
alternatively
1conf, err := c.Query(time.Now())
Go interfaces generally belong in the package that uses values of the interface type, not the package that implements those values. Go Code Review Comments
Define interfaces in the consuming story, where it declares what support it needs from its dependencies.
"When your main package drives the interaction model, it opens up flexibility to receive help from other packages in various different ways it also allows the supporting packages to be looked at more independently, developed on its own"