Program initialization order
Package initialization follows dependency order plus declaration dependencies; `init` behavior only makes sense in that larger model.
Canonical guidance
- imported packages initialize before the importing package
- package-level variables initialize before
initruns initfunctions run after variable initialization, in file order within the package build
Use when
- debugging surprising startup behavior
- reviewing registration patterns
- explaining package-level side effects
Avoid
- relying on obscure initialization order between unrelated files
- placing expensive I/O or hidden control flow in package initialization casually
- assuming
initis a substitute for explicit application wiring
Preferred pattern
var defaultTimeout = 5 * time.Second
Anti-pattern
- depending on fragile package init side effects across distant imports to make ordinary runtime wiring work
Explanation: This is tempting because it removes explicit setup calls, but it also hides control flow inside startup order.
Why
- initialization order questions often look like style questions until the exact spec rule determines behavior