Programming Best Practices

Motivation

A quick & easy summarized version of original go link

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.

Godoc will present this example alongside the actual function's documentation

func ExampleReverse() {
fmt.Println(stringutil.Reverse("hello"))
// Output: olleh
}

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

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.
- Finally, when in doubt, use a pointer receiver.