Every package should have a single purpose and the best way to know a package's purpose is by its name - a noun
Simplicity matters
Simple means readable, understandable, maintainable, reliable, relatable
Simplicity is prerequisite of reliability
Simple code is preferable to clever code
Explicit is better than implicit.
How to achieve it
Avoid package level state
Because of:
we can't test it in isolation, in parallel
we can't use more then one instance at a time
Low coupling and high cohesion
Plan for failure, not success
Every error should be handled
Return early rather than nesting deeply
Avoid control flow that requires deep indentation
Use guard closes (сторожевые методы)
Place the successful return statement at the end of function
Reduce an indentation by extracting logic in another functions and methods
if you think it’s slow, prove it with a benchmark
Don’t complicate your code because of outdated dogma, and, if you think something is slow, first prove it with a benchmark.
Before you launch a goroutine, know when it will stop
Before you launch a goroutine answer on questions:
Under what condition will a goroutine stop?
What is required for that condition to arise?
What signal will you use to know the goroutine has stopped?
Leave concurrency to the caller
Let the caller choose how they want to start, track, and wait on your functions execution.
Write tests to lock in the behaviour of your package’s API
Your tests are the contract about what your software does and does not do
Maintainability counts
The real goal is to write maintainable code. Code that can live on after the original author. Code that can exist not just as a point in time investment, but as a foundation for future value. It’s not that readability doesn’t matter, maintainability matters more.