A quick & easy summarized version of original go link
Error strings
should not be capitalized (unless beginning with proper nouns or acronyms) or end with punctuation, since they are usually printed following other context.
fmt.Errorf("something good")
fmt.Errorf("This is bad")
Imagine how it might be used
// do not expect a spurious capital letter mid-message
log.Printf("Reading %s: %v", filename, err)
This does not apply to logging, which is implicitly line-oriented and not combined inside other messages.
Testable Examples
Like unit tests they reside in _test.go file
Unlike unit test functions they do not take arguments
Godoc will present this example alongside the actual function's documentation
They are good but should be a necessity than a norm
When the need for common behaviours with differing implementations
e.g. Speak() is a behaviour which can vary widely in a package
then go for type Speaker interface with Speak() as interface method
Don't push an Object to confirm an Interface
Push the object's behaviour to confirm an Interface when similar such behaviours with differing implementations are found in multiple objects
Don't push a method to confirm an Interface just because you want to mock it for Unit Testing
Instead create a Mock structure that composes the original struct to be mocked
To use a Value or Pointer Receiver ?
If in doubt, use a pointer, but there are times when a value receiver makes sense, usually for reasons of efficiency, such as for small unchanging structs or values of basic type.
Guidelines
If the method needs to mutate the receiver, the receiver must be a pointer.
If the receiver is a struct that contains a sync.Mutex or similar synchronizing field, the receiver must be a pointer to avoid copying.
If the receiver is a large struct or array, a pointer receiver is more efficient. How large is large? Assume it's equivalent to passing all its elements as arguments to the method. If that feels too large, it's also too large for the receiver.
If the receiver is a struct, array or slice and any of its elements is a pointer to something that might be mutating, prefer a pointer receiver, as it will make the intention more clear to the reader.
If the receiver is a small array or struct that is naturally a value type (for instance, something like the time.Time type), with no mutable fields and no pointers, or is just a simple basic type such as int or string, a value receiver makes sense.
Motivation
A quick & easy summarized version of original go link
Error strings
Testable Examples
Do not start with Interfaces
To use a Value or Pointer Receiver ?