Import style

Canonical guidance

• keep import blocks simple and predictable
• rename imports only when collision or clarity requires it
• reserve blank imports for deliberate side effects
• reserve dot imports for rare cases such as tests where they materially improve readability

Use when

• reviewing import blocks
• resolving naming collisions
• checking side-effect imports

Avoid

• stylistic import aliases with no real benefit
• dot imports in ordinary production packages
• leaving stale blank imports after registration needs disappear

Preferred pattern

import (
	"context"
	"net/http"
)

Anti-pattern

• renaming nearly every import in a file because the local names feel more personal

Explanation: This is tempting when curating local aesthetics, but readers should not have to decode a custom alias layer in every file.

Why

• import style is low-level but constant review traffic, and Google’s detailed rules help keep it uniform