Build tags

Canonical guidance

• use build constraints for real compile-time differences
• prefer //go:build in modern code
• keep constrained files small and obvious
• choose runtime configuration when behavior should vary without recompilation

Use when

• OS- or architecture-specific files
• optional cgo integrations
• toolchain-specific implementations

Avoid

• hiding ordinary business logic behind build tags
• complex boolean expressions without clear need
• using build tags for per-environment configuration

Preferred pattern

//go:build linux

package poller

Anti-pattern

• scattering application features across many build-tag combinations

Explanation: This anti-pattern is tempting when feature flags feel compile-time friendly, but it makes builds harder to reason about and test.

Why

• build constraints are for compile-time portability and toolchain boundaries