golang-patterns

Topics in the source

• Go Development Patterns
• When to Activate
• Core Principles
• 1. Simplicity and Clarity
• 2. Make the Zero Value Useful
• 3. Accept Interfaces, Return Structs
• Error Handling Patterns
• Error Wrapping with Context

Idiomatic Go patterns and best practices for building robust, efficient, and maintainable applications. Writing new Go code Reviewing Go code Refactoring existing Go code Designing Go packages/modules Go favors simplicity over cleverness. Code should be obvious and easy to read. Design types so their zero value is immediately usable without initialization. Functions should accept interface parameters and return concrete types. Never return or retain buf.Bytes() from a pooled buffer past Put: copy it, or let the caller pass in an io.Writer so no copy is needed. | Idiom | Description | |-------|-------------| | Accept interfaces, return structs | Functions accept interface params, return concrete types | | Errors are values | Treat errors as first-class values, not exceptions | | Don't communicate by sharing memory | Use channels for coordination between goroutines | | Make the zero value useful | Types should work without explicit initialization | | A little copying is better than a little dependency | Avoid unnecessary external dependencies | | Clear is better than clever | Prioritize readability over cleverness | | gofmt is no one's favorite but everyone's friend | Always format w

This is an excerpt. Refer to the complete source and its current requirements.