Teams often compress too much logic into one expression. That makes the code harder to scan, because readers must parse both the assignment and the surrounding expression to understand what actually happens. The cleaner pattern is to assign on one line, then return or use the value on the next line. This keeps state changes explicit and easier to review.
In this pattern, the concern is not the assignment itself, but the way it hides work inside a larger expression. Readers should not have to mentally unpack side effects while also following a return value or function call. The real issue is readability and reviewability, especially when the expression gets nested or reused.
When code compresses state changes into an expression, it becomes harder to see what value was computed, whether it was intentionally retained, and whether the assignment has any side effects. That makes bugs easier to miss during review and refactoring. A separate assignment line usually makes the flow clearer without changing behaviour.
The practical rule is simple: if the assignment exists to make the next step possible, give it its own line. If the value is only needed once, the separate line still helps when the expression would otherwise mix computation, mutation, and control flow. The clearer shape is usually easier to test, log, and modify later.
Risk and Threat Considerations
Compressed assignments can create a subtle maintenance risk because reviewers may focus on the return or function call and overlook a value change that affects later logic. In security-sensitive code, that kind of hidden state change can turn into incorrect authorization decisions, incomplete validation, or brittle error handling.
Failure mechanism: The code path mixes assignment with another operation, so the state update is easy to miss, easy to reorder incorrectly, and harder to reason about during review or refactoring.
Impact: Small readability failures can become logic defects, especially where a computed value feeds access control, validation, or downstream branching.
Practitioner Guidance
What to prioritise: Prefer the form that makes the state change obvious at a glance. If a reader has to pause to determine whether the assignment is part of the return value or just preparation for it, split it into two statements.
What to verify: Check whether the assignment is doing more than capturing a value for immediate use. If it also signals a meaningful state transition, separate it so reviewers can see the transition before they see the use.
Common mistake: Treating compact syntax as automatically better style. Brevity is useful only when it does not make intent harder to inspect, especially in code paths that will be maintained by others.
Practitioner takeaway: Use expression-level assignment sparingly; if the line hides meaning, the cleaner implementation is the one that makes the state change explicit before the return or call.
Related resources from NHI Mgmt Group
- What do teams get wrong about using breadcrumbs and lures for deception-based detection?
- What do teams get wrong about using configuration automation tools for user access?
- What do teams get wrong about RBAC and PAM in hybrid cloud banking security?
- What do teams get wrong about making security ownership shared across developers and CTOs?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 26, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
