When accepting a slice or map from external snippet or returning one, consider copying it. This prevents unintentional modifications to the original data. For example, don't store a slice argument directly if the caller might modify it later; instead, make a copy for internal use.
Slices and maps hold references to underlying data. If you keep a reference to a slice or map provided by someone else, changes in one will affect the other, potentially causing bugs or data races. Copying ensures your snippet has its own independent data, improving safety and clarity.
Side-by-side examples engineers can pattern-match during review.
type Config struct {
allowed []string
}
func (c *Config) SetAllowed(a []string) {
c.allowed = a // storing reference directly
}
// ... elsewhere
cfg := &Config{}
list := []string{"val1", "val2"}
cfg.SetAllowed(list)
list[0] = "changed" // unintended: also changes cfg.allowedfunc (c *Config) SetAllowed(a []string) {
copySlice := make([]string, len(a))
copy(copySlice, a)
c.allowed = copySlice // store a copy
}
// Now modifying the original 'list' won't affect c.allowedtype Config struct {
allowed []string
}
func (c *Config) SetAllowed(a []string) {
c.allowed = a // storing reference directly
}
// ... elsewhere
cfg := &Config{}
list := []string{"val1", "val2"}
cfg.SetAllowed(list)
list[0] = "changed" // unintended: also changes cfg.allowedfunc (c *Config) SetAllowed(a []string) {
copySlice := make([]string, len(a))
copy(copySlice, a)
c.allowed = copySlice // store a copy
}
// Now modifying the original 'list' won't affect c.allowedFrom the same buckets as this rule.
For changes that affect architecture, data models, external APIs, security posture, deployment topology, or cost (>10%), create an ADR in docs/adr/ using the standard template (Context, Decision, Consequences) and link the PR and issue IDs.