Struct tags

Canonical guidance

• use tags for narrow metadata at boundaries
• keep tag semantics stable and well-known
• prefer explicit code when tags start encoding too much behavior

Use when

• JSON or DB mapping
• validation libraries
• framework or serialization hints

Avoid

• tags that act like a second programming language
• hidden business rules encoded only in metadata
• many overlapping tag systems on one type

Preferred pattern

type User struct {
	ID   string `json:"id"`
	Name string `json:"name"`
}

Anti-pattern

• relying on undocumented tag strings to drive large parts of application behavior

Explanation: This anti-pattern is tempting because tags look lightweight, but hidden metadata quickly becomes hard to reason about and refactor.

Why

• struct tags work best as a small boundary hint, not a logic engine