Best Practices for Pointers vs. Values in Parameters and Return Values in Go

In Go programming, choosing between pointers and values for parameter passing and return values is a common and important consideration. This choice affects not only performance and memory usage but also program correctness and maintainability. Based on community best practices and official guidelines, this article systematically analyzes selection strategies for various scenarios.

Choosing Receiver Types

For method receivers, pointers are generally preferred. According to Go code review guidelines, when in doubt, use a pointer receiver. This is primarily because methods often need to modify the receiver's state, or the receiver type might be a large struct. Pointer receivers avoid the overhead of value copying while allowing methods to modify the original object.

Consider a user management system scenario:

type User struct {
    ID       int
    Name     string
    Email    string
    IsActive bool
}

// Pointer receiver for modification
func (u *User) Activate() {
    u.IsActive = true
}

// Value receiver for read-only operations
func (u User) GetName() string {
    return u.Name
}

Tools like copyfighter can help identify cases where non-tiny receivers are passed by value, but the final decision should be based on semantic needs rather than size alone.

Pointers vs. Values in Function Parameters

For regular function parameters, the strategy differs. Small structs should typically be passed by value, avoiding unexpected aliasing effects—where modifying data through one pointer inadvertently affects other code using the same data. Value semantics provide better locality and can sometimes offer performance benefits by reducing cache misses and heap allocations.

The Go code review guidelines suggest passing small structs that are likely to remain small by value. The definition of "small" is somewhat vague, but some rules of thumb exist: slices (three machine words) are often suitable as value receivers, while functions like bytes.Replace accept arguments totaling 10 words. The key is balancing performance with code clarity.

// Small struct suitable for value passing
type Point struct {
    X, Y float64
}

func CalculateDistance(p1, p2 Point) float64 {
    dx := p1.X - p2.X
    dy := p1.Y - p2.Y
    return math.Sqrt(dx*dx + dy*dy)
}

// Large or modifiable struct suitable for pointer passing
type Config struct {
    Settings map[string]interface{}
    // ... many other fields
}

func UpdateConfig(c *Config, key string, value interface{}) {
    c.Settings[key] = value
}

Special Handling of Reference Types

Slices, maps, channels, strings, function values, and interface values already contain pointers or references internally, so additional pointer wrapping is usually unnecessary. For example, the io.Reader.Read(p []byte) function modifies byte content through a slice parameter without needing a pointer to the slice.

A slice header is a small struct containing a pointer to the underlying array, length, and capacity. When passing a slice by value, this header is copied, but the underlying array remains unchanged, allowing modification of array elements. Different patterns are needed only when modifying the slice itself, such as reslicing.

// No pointer needed to modify slice elements
func ProcessData(data []byte) {
    for i := range data {
        data[i] = data[i] * 2
    }
}

// Returning a new slice (following the append pattern)
func FilterUsers(users []User, predicate func(User) bool) []User {
    result := []User{}
    for _, user := range users {
        if predicate(user) {
            result = append(result, user)
        }
    }
    return result
}

Memory Reuse and Optimization Strategies

Memory reuse via pointer parameters requires caution. Premature optimization can complicate APIs, burdening all users. Better strategies include:

1. Leveraging Go's escape analysis to help the compiler avoid heap allocations through simple constructors, literals, or useful zero values like bytes.Buffer.
2. Providing a Reset() method to return an object to a blank state, allowing memory-conscious users to opt in.
3. Creating pairs of modify-in-place methods and create-from-scratch functions, such as existingUser.LoadFromJSON() and NewUserFromJSON().
4. Considering sync.Pool for memory recycling in cases of specific memory pressure.

Value Elements vs. Pointer Elements in Slices

When choosing between storing values or pointers in slices, several factors should be considered:

• Creation API: If you must use NewFoo() *Foo instead of zero-value initialization, pointers may be forced.
• Lifetime Management: If elements in the slice have different lifetimes, pointer slices may be more appropriate, as value slices release all elements simultaneously.
• Impact of Move Operations: Operations like append, insertion, deletion, and sorting move elements. For large structs or those containing non-copyable types like sync.Mutex, pointers may be preferable.

Value slices may be optimal when all elements are obtained upfront and not moved afterward, or when elements are moved frequently but are small and performance impact has been measured. Pointer slices offer more flexible lifetime management and avoid copying large structs.

// Value slice: suitable for small, statically set structs
type SmallItem struct {
    ID   int
    Name string
}

func GetStaticItems() []SmallItem {
    return []SmallItem{
        {ID: 1, Name: "Item1"},
        {ID: 2, Name: "Item2"},
        {ID: 3, Name: "Item3"},
    }
}

// Pointer slice: suitable for large or independently managed structs
type LargeItem struct {
    Data [1000]byte
    // ... other large fields
}

func ProcessLargeItems(items []*LargeItem) {
    for _, item := range items {
        // Process large items, avoiding copies
    }
}

In practice, these factors should be weighed based on specific needs. Go's design philosophy emphasizes simplicity and clarity, so when performance differences are minimal, the semantically clearer option should be chosen. By understanding these principles, developers can make informed design decisions and write efficient, maintainable Go code.