Go Best Practices Skill

Apply idiomatic Go patterns and best practices from Gopher Guides training materials.

When Helping with Go Code

Error Handling

• •Wrap errors with context: Use fmt.Errorf("operation failed: %w", err)
• •Check errors immediately: Don't defer error checking
• •Return errors, don't panic: Panics are for unrecoverable situations only
• •Create sentinel errors for expected conditions: var ErrNotFound = errors.New("not found")
• •Use errors.Is() and errors.As() for error comparison

// Good
if err != nil {
    return fmt.Errorf("failed to process user %s: %w", userID, err)
}

// Avoid
if err != nil {
    log.Fatal(err)  // Don't panic on recoverable errors
}

Interface Design

• •Accept interfaces, return structs: Functions should accept interfaces but return concrete types
• •Keep interfaces small: Prefer single-method interfaces
• •Define interfaces at point of use: Not where the implementation lives
• •Don't export interfaces unnecessarily: Only if users need to mock

// Good - interface defined by consumer
type Reader interface {
    Read(p []byte) (n int, err error)
}

func ProcessData(r Reader) error { ... }

// Avoid - exporting implementation details
type Service interface {
    Method1() error
    Method2() error
    Method3() error  // Too many methods
}

Concurrency

• •Don't communicate by sharing memory; share memory by communicating
• •Use channels for coordination, mutexes for state
• •Always pass context.Context as first parameter
• •Use errgroup for coordinating goroutines
• •Avoid goroutine leaks: Ensure goroutines can exit

// Good - using errgroup
g, ctx := errgroup.WithContext(ctx)
for _, item := range items {
    item := item  // capture loop variable
    g.Go(func() error {
        return process(ctx, item)
    })
}
if err := g.Wait(); err != nil {
    return err
}

Testing

• •Use table-driven tests for multiple scenarios
• •Call t.Parallel() for independent tests
• •Use t.Helper() in test helpers
• •Test behavior, not implementation
• •Use testify for assertions when it improves readability

func TestAdd(t *testing.T) {
    tests := []struct {
        name string
        a, b int
        want int
    }{
        {"positive numbers", 2, 3, 5},
        {"with zero", 5, 0, 5},
        {"negative numbers", -2, -3, -5},
    }

    for _, tt := range tests {
        t.Run(tt.name, func(t *testing.T) {
            t.Parallel()
            got := Add(tt.a, tt.b)
            if got != tt.want {
                t.Errorf("Add(%d, %d) = %d, want %d", tt.a, tt.b, got, tt.want)
            }
        })
    }
}

Package Organization

• •Package names should be short and lowercase: user not userService
• •Avoid package-level state: Use dependency injection
• •One package per directory: No multi-package directories
• •internal/ for non-public packages: Prevents external imports

Naming Conventions

• •Use MixedCaps or mixedCaps: Not underscores
• •Acronyms should be consistent: URL, HTTP, ID (all caps for exported, all lower otherwise)
• •Short names for short scopes: i for loop index, err for errors
• •Descriptive names for exports: ReadConfig not RC

Code Organization

• •Declare variables close to use
• •Use defer for cleanup immediately after resource acquisition
• •Group related declarations
• •Order: constants, variables, types, functions

Anti-Patterns to Avoid

• •Empty interface (interface{} or any): Use specific types when possible
• •Global state: Prefer dependency injection
• •Naked returns: Always name what you're returning
• •Stuttering: user.UserService should be user.Service
• •init() functions: Prefer explicit initialization
• •Complex constructors: Use functional options pattern

When in Doubt

• •Refer to Effective Go
• •Check the Go standard library for examples
• •Use go vet and staticcheck for automated guidance

This skill is powered by Gopher Guides training materials. For comprehensive Go training, visit gopherguides.com.