열기와 닫기 짝짓기

Resources come in pairs: open and close, alloc and free, lock and unlock. The skill is keeping each pair balanced.

The Zig habit is to write the close immediately after the open, using defer, so the pair can never drift apart.

The same rhythm applies to memory. Right after you allocate, schedule the free so the buffer is released on exit.

Mutexes follow suit. Acquire the lock, then defer the unlock so the lock is always released even if you return early.

Open several things and each gets its own defer. The reverse order ensures they close in the right sequence automatically.

When a function builds and returns a resource, use errdefer for the free, so it survives on success but is cleaned up on error.

Because the close sits with the open, refactoring or adding branches never leaves a resource orphaned and leaking.

A reviewer can scan for each open and immediately spot its matching defer. Missing cleanup becomes obvious at a glance.

Think of it as symmetry: every acquiring line has a releasing line nearby, and the defer keeps them in lockstep.

Acquire, then defer release, then use. This three-step recipe covers files, memory, locks, and almost any resource you meet.

With paired acquire and release, you can add early returns and error handling freely, trusting cleanup to stay correct.

Where should the matching close usually go?

Pair every open with a defer close on the next line. This symmetry keeps files, memory, and locks balanced on all paths. 🔐