Golang

Go Development Instructions

Follow idiomatic Go practices and community standards when writing Go code. These instructions are based on Effective Go, Go Code Review Comments, and Google's Go Style Guide.

General Instructions

• Write simple, clear, and idiomatic Go code
• Favor clarity and simplicity over cleverness
• Follow the principle of least surprise
• Keep the happy path left-aligned (reduce indentation)
• Return early to reduce nesting
• Make the zero value useful
• Document exported types, functions, methods, and packages
• Use Go modules for dependency management
• AVOID else statements - use early returns, continue, or break instead
• Avoid wrapping primitives without a clear semantic benefit; define new types when they add meaning.
• Use typed slices/maps and document element semantics when not obvious.
• Start error strings with a lowercase letter.

Naming Conventions

Packages

• Use lowercase, single-word package names
• Avoid _ characters, hyphens, or mixedCaps
• Choose names that describe what the package provides, not what it contains
• Avoid generic names like util, common, or base
• Package names should be singular, not plural

Variables and Functions

• Use mixedCaps or MixedCaps (camelCase) rather than _ characters
• Keep names short but descriptive
• Use single-letter variables for very short scopes (like loop indices)
• Exported names start with a capital letter
• Unexported names start with a lowercase letter
• Avoid stuttering (e.g., avoid http.HTTPServer, prefer http.Server)

Interfaces

• Name interfaces with -er suffix when possible (e.g., Reader, Writer, Formatter)
• Single-method interfaces should be named after the method (e.g., Read → Reader)
• Keep interfaces small and focused

Constants

• Use MixedCaps for exported constants
• Use mixedCaps for unexported constants
• Group related constants using const blocks
• Consider using typed constants for better type safety

Code Style and Formatting

Formatting

• Always use gofmt to format code
• Use goimports to manage imports automatically
• Keep line to 180 max at all times
• Add blank lines to separate logical groups of code

Comments

• Write comments in complete sentences
• Start sentences with the name of the thing being described
• Package comments should start with "Package [name]"
• Use line comments (//) for most comments
• Use block comments (/* */) sparingly, mainly for package documentation
• Document why, not what, unless the what is complex

Error Handling

• Check errors immediately after the function call
• Don't ignore errors using _ unless you have a good reason (document why)
• Wrap errors with context using fmt.Errorf with %w verb
• Create custom error types when you need to check for specific errors
• Place error returns as the last return value
• Name error variables err
• Keep error messages lowercase and don't end with punctuation

Logging

• Always use the codebase log package for logging
• Log errors at the point they occur using log.Error(err)
• Do not format the errors, let the log package handle it
• For complex function calls, use defer log.Trace(time.Now(), args) where args are the function arguments at the start of the function.

Control Flow

• NEVER use else statements - they create unnecessary nesting and reduce readability
• Use early returns to handle error cases and edge conditions first
• Use continue in loops to skip to the next iteration instead of nesting
• Use break to exit loops early instead of complex conditional logic
• Keep the main logic (happy path) left-aligned with minimal indentation

❌ BAD - Don't do this:

func processEntry(entry *Entry) string {
    if entry.Expired() {
        return "expired"
    } else {
        if entry.TTL < 0 {
            return "never expires"
        } else {
            return fmt.Sprintf("expires at %s", time.Unix(entry.Timestamp, 0))
        }
    }
}

✅ GOOD - Do this instead:

func processEntry(entry *Entry) string {
    if entry.Expired() {
        return "expired"
    }

    if entry.TTL < 0 {
        return "never expires"
    }

    return fmt.Sprintf("expires at %s", time.Unix(entry.Timestamp, 0))
}

❌ BAD - Nested loop logic:

for _, item := range items {
    if item.IsValid() {
        if item.ShouldProcess() {
            // complex processing logic
        }
    }
}

✅ GOOD - Early continue:

for _, item := range items {
    if !item.IsValid() {
        continue
    }
    if !item.ShouldProcess() {
        continue
    }

    // complex processing logic (happy path)
}

Architecture and Project Structure

Package Organization

• Follow standard Go project layout conventions
• Group related functionality into packages
• Avoid circular dependencies

Dependency Management

• Use Go modules (go.mod and go.sum)
• Keep dependencies minimal
• Regularly update dependencies for security patches
• Use go mod tidy to clean up unused dependencies
• Vendor dependencies when necessary

Type Safety and Language Features

Type Definitions

• Define types to add meaning and type safety
• Use struct tags for JSON, YAML and TOML on exported fields
• Prefer explicit type conversions
• Use type assertions carefully and check the second return value

Pointers vs Values

• Use pointers for large structs or when you need to modify the receiver
• Use values for small structs and when immutability is desired
• Be consistent within a type's method set
• Consider the zero value when choosing pointer vs value receivers

Interfaces and Composition

• Accept interfaces, return concrete types
• Keep interfaces small (1-3 methods is ideal)
• Use embedding for composition
• Define interfaces close to where they're used, not where they're implemented
• Don't export interfaces unless necessary

Concurrency

Goroutines

• Don't create goroutines in libraries; let the caller control concurrency
• Always know how a goroutine will exit
• Use sync.WaitGroup or channels to wait for goroutines
• Avoid goroutine leaks by ensuring cleanup

Channels

• Use channels to communicate between goroutines
• Don't communicate by sharing memory; share memory by communicating
• Close channels from the sender side, not the receiver
• Use buffered channels when you know the capacity
• Use select for non-blocking operations

Synchronization

• Use sync.Mutex for protecting shared state
• Keep critical sections small
• Use sync.RWMutex when you have many readers
• Prefer channels over mutexes when possible
• Use sync.Once for one-time initialization

Error Handling Patterns

Creating Errors

• Use errors.New for simple static errors
• Use fmt.Errorf for errors with runtime values
• Create custom error types for domain-specific errors
• Export error variables for sentinel errors
• Use errors.Is and errors.As for error checking

Error Propagation

• Add context when propagating errors up the stack
• Don't log and return errors (choose one)
• Handle errors at the appropriate level
• Consider using structured errors for better debugging

Performance Optimization

Memory Management

• Minimize allocations in hot paths
• Reuse objects when possible (consider sync.Pool)
• Use value receivers for small structs
• Preallocate slices when size is known
• Avoid unnecessary string conversions

Profiling

• Use built-in profiling tools (pprof)
• Benchmark critical code paths
• Profile before making performance changes
• Focus on algorithmic improvements first
• Consider using testing.B for benchmarks

Testing

Test Organization

• Keep tests in the same package (white-box testing)
• Use _test package suffix for black-box testing
• Name test files with _test.go suffix
• Place test files next to the code they test

Writing Tests

• Name tests descriptively using TestFunctionNameScenario
• Use subtests with t.Run for better organization
• Test both success and error cases
• Use testify/assert and testify/require for assertions
• Include both positive and negative test cases
• Test edge cases and error conditions
• When including a standard library that conflicts with an existing import, use the lib(library name) pattern to avoid conflicts. Such as: libtime for the time package.

Test behavior, not the patch

Before adding a test, name the observable behavior or invariant it proves. A regression test must fail on the code before the fix for the same reason as the reported bug, pass after the fix, and permit correct internal refactors.

Do not add tests that inspect source code or embedded text for a symbol, statement, condition, string, or the relative order of statements in the code. Such tests prove that a patch has a particular shape, not that the behavior works. Text assertions are appropriate when the emitted text is itself the contract, such as generated commands, escaping, serialization, or required output encoding.

Test behavior in the runtime that owns it. A Go test must not inspect an embedded shell script to claim that shell host behavior works; use a shell integration test instead. If the available infrastructure cannot exercise the regression, state the missing coverage and required manual verification rather than adding a proxy test that cannot catch the bug.

Use these checks for every new test:

1. Could the original bug still occur while this test passes?
2. Could a correct refactor make this test fail?

If either answer is yes, redesign or remove the test.