Will It Vibe?defer used inside a for loop
Part of Code Quality & Syntax, which counts for 20% of the overall score. When this check fires it deducts 8 points from that category, once per scan, no matter how many places it turns up.
What it detects
defer only runs when the enclosing function returns, not at the end of a loop iteration, so a defer inside a for loop accumulates one deferred call per iteration and holds every resource open until the function exits instead of releasing it each pass.
Why it matters
defer schedules a call to run when the enclosing function returns, not when the current loop iteration ends. Placed inside a for loop, every iteration adds another deferred call that all pile up and only run together at the very end of the function, so a loop that opens a hundred files holds all hundred open (and the OS file-descriptor limit close) until the function returns, instead of closing each one as soon as it is done with it.
How to fix it
Move the deferred call into a separate function (or an inline closure invoked immediately) scoped to a single iteration, so each iteration's defer actually runs when that iteration's work is done: for _, item := range items { func() { f := open(item); defer f.Close(); process(f) }() }. If the loop must keep resources open across iterations for a real reason, close them explicitly instead of using defer.
The paid report includes a ready-to-paste prompt for your AI coding agent for every check it finds, pointed at the exact findings from your scan. See pricing
Does your repo trip this check?
Paste a GitHub URL or drop a project folder. Scans run in your browser and take seconds.
Scan your repo