Ignoring the value in destructuring avoids creating an extra variable at all, while naming it with an underscore still creates an assignment that serves mainly as a human signal. If the value is not needed, direct omission is cleaner because it reduces noise in the code and avoids triggering unused-variable rules.
Why the distinction matters in code style
Ignoring a destructured value omits it from the pattern entirely, so the language never creates a binding for it. Assigning the same value to an underscore variable still creates a variable, even if the name is chosen to signal “intentionally unused.” That difference matters because tools, linters, and reviewers treat omission as cleaner intent and underscore bindings as an explicit placeholder.
In practice, direct omission is usually the better choice when you do not need the value at all. It keeps the destructuring pattern aligned with the actual data you care about and avoids extra noise. The underscore form is mainly useful when you want to show that a value was intentionally received but discarded, or when a style guide requires a named placeholder.
For readers maintaining shared code, the key distinction is readability versus explicitness. Omission says the value is irrelevant to the operation. Underscore says the value exists in the contract, but this particular site of the code does not use it. Those are close signals, but they are not identical.
How linters and compilers usually interpret each form
Most unused-variable rules focus on whether a binding was created and then never used. Because omission creates no binding, it often avoids the warning entirely. An underscore variable may still be counted as a binding, and depending on the language or lint configuration, it may either be exempted by convention or still flagged if the rule is strict.
This means the safer default is to prefer omission when the value is truly unnecessary. If you use an underscore variable, you are relying on a naming convention rather than on the structure of the destructuring itself. That can be fine in teams that have agreed on the convention, but it is a weaker signal than not creating the variable in the first place.
The practical consequence is consistency. If your codebase and tooling are tuned to treat underscore placeholders as intentional, the pattern can be acceptable. If not, direct omission reduces friction and makes automated checks easier to satisfy without exceptions or special cases.
When the underscore placeholder is still the right choice
The underscore form is sometimes the better communicative choice when the code wants to document that a position in the destructured structure is deliberate even though it is not used. That can help in code reviews where the shape of the returned tuple or object matters, especially if other parts of the same function use adjacent values from the same destructure.
It is also useful when a team uses underscore placeholders as a standard convention for “I am receiving this slot, but I do not need it here.” In that case the underscore can be a readability aid, not a technical necessity. The trade-off is that it introduces a binding that may need special lint handling, so it is best used deliberately rather than by habit.
For destructuring assignments that must stay visually aligned, underscore placeholders can preserve structure. Still, if the extra name adds no meaning and the codebase does not depend on that convention, omission is the cleaner default.
Practitioner Guidance
What to prioritise: Prefer omission when the value has no role in the local logic. Reach for an underscore placeholder only when the team benefits from an explicit “intentionally unused” signal or when the destructured shape itself is worth preserving for readability.
What to verify: Check how your linter and language treat underscore bindings before standardising on them. If the rule still reports them as unused, the underscore is adding noise rather than reducing it.
Common mistake: Using underscore variables by default because they feel safer. In many codebases that simply creates an avoidable binding, which is exactly what omission was meant to prevent.
Practitioner takeaway: If you do not need the value, omit it from destructuring; use an underscore only when the placeholder itself carries meaning for readers or tooling.
Related resources from NHI Mgmt Group
- What is the difference between compliance metrics and identity value metrics?
- What is the difference between pricing for usage and pricing for value?
- What is the difference between measuring AI token usage and measuring business value?
- What is the difference between using a special value and using Spring profiles to switch between live and mocked integrations?
