Skip to content

Latest commit

 

History

History
72 lines (50 loc) · 2.55 KB

File metadata and controls

72 lines (50 loc) · 2.55 KB

Contributing to Go Design Patterns

Thanks for your interest in contributing! This is an actively maintained collection of Go design and application patterns. Whether you're fixing a typo, improving an existing pattern, or proposing a new one, your help is appreciated.

Ways to Contribute

  • Improve existing patterns — better examples, clearer explanations, bug fixes in code snippets
  • Add new patterns — propose patterns not yet covered (open an issue first to discuss)
  • Fix issues — check the open issues for things to work on
  • Review — read through patterns and report anything unclear or incorrect

Getting Started

  1. Fork this repository
  2. Create a feature branch: git checkout -b <category>/<pattern-name>
  3. Make your changes
  4. Commit following the message guidelines below
  5. Push to your fork and open a pull request

Pull Request Guidelines

  • Make an individual pull request for each suggestion.
  • Choose the corresponding patterns section for your suggestion.
  • List, after your addition, should be in lexicographical order.
  • Ensure Go code snippets compile and are idiomatic — use gofmt style.
  • Keep examples minimal and focused. Avoid unnecessary boilerplate.

Commit Messages Guidelines

  • The message should be in imperative form and uncapitalized.
  • If possible, please include an explanation in the commit message body.
  • Use the form <pattern-section>/<pattern-name>: <message>
    • e.g. creational/singleton: refactor singleton constructor
    • e.g. behavioral/visitor: fix interface example

Pattern Template

Each pattern should have a single markdown file containing the important part of the implementation, the usage and the explanations for it. This is to ensure that the reader doesn't have to read a bunch of boilerplate to understand what's going on and the code is as simple as possible and not simpler.

Please use the following template for adding new patterns:

# <Pattern-Name>
<Pattern description>

## Implementation

```go
// Go implementation here

Usage

// Usage example here

Rules of Thumb

  • Bullet points with practical advice

## Code Style

- All Go code should follow standard `gofmt` formatting
- Use meaningful variable and function names
- Include comments only where the logic isn't self-evident
- Prefer standard library packages over external dependencies
- Use Go generics where they improve clarity (Go 1.18+)

## Questions?

Open an issue if you're unsure about anything. We're happy to help!