Clever one-liners are satisfying to write and, more often than we’d like to admit, genuinely bad for a codebase’s long-term maintainability - the gap between “impressive JavaScript trick” and “code a teammate can understand at 2am during an incident” is real, and it’s worth being honest about which side of that line a given pattern actually falls on before it ships.
Where compact, clever code is genuinely worth it
Well-established, widely-understood functional patterns - array methods chained cleanly (`.filter().map().reduce()`), optional chaining and nullish coalescing for concise null-safety, destructuring for clean extraction of values - are compact without being obscure, because any experienced JavaScript developer recognizes the pattern instantly. These earn their conciseness because the pattern itself is common knowledge, not a personal cleverness that requires the reader to reverse-engineer intent.
Where “rigor” actually means readability, not compression
The instinct to compress logic into the fewest possible characters - nested ternaries, deeply chained optional operations, bitwise tricks used for their cleverness rather than genuine necessity - optimizes for the wrong thing. Engineering rigor in a production codebase isn’t about how few characters a line uses; it’s about how quickly and correctly the next person (often you, months later) can understand what the code does and why. A slightly longer, clearly-named, well-structured version of the same logic is the more rigorous choice, not the less sophisticated one.
Specific patterns worth genuine caution around
- Nested ternaries - a single ternary is fine; nesting them to handle multiple conditions compresses real branching logic into a form that’s genuinely harder to parse correctly than an explicit if/else chain or a switch statement, despite being fewer lines.
- Deeply chained method calls without intermediate names - a long chain of transformations with no named intermediate steps forces a reader to mentally trace the entire chain to understand any single step’s purpose, versus breaking it into named, self-documenting intermediate variables.
- Regex used where a clearer, more verbose alternative exists - a complex regex pattern is often more compactly “clever” than a few lines of explicit string parsing, and also often meaningfully harder for a future maintainer (possibly not the original author) to safely modify without introducing a subtle bug.
What we actually optimize for in code review
We push back on code that requires the reader to be genuinely clever to understand it, regardless of how elegant the author found it while writing it - the actual measure of good code is how quickly a competent but unfamiliar reader can correctly understand and safely modify it, not how impressively compressed it is. This isn’t an argument for verbose, unnecessarily long code either - it’s an argument for optimizing for clarity as the primary goal, with compactness as a secondary benefit when it doesn’t cost clarity.
What we’d actually recommend
Before shipping a clever one-liner, honestly ask whether a teammate unfamiliar with that specific pattern would understand it correctly on first read, under time pressure, without needing to trace through it carefully - if the honest answer is no, the more explicit, slightly longer version is the more rigorous engineering choice, not the less impressive one.
We enforce this discipline through code review standards on every engineering project we run. Talk to us if you want a code quality review that prioritizes long-term maintainability over surface cleverness.