DEV Community

Cover image for Modern Code, Ancient Habits: Why Your One-Liners and Cryptic Names Aren't Clever
Adam - The Developer
Adam - The Developer

Posted on

Modern Code, Ancient Habits: Why Your One-Liners and Cryptic Names Aren't Clever

#programming #cleancode #codequality #javascript

We live in 2025. We've got 32GB RAM machines, terabytes of storage, AI-powered IDEs, and linters that fix your code before you even blink.
And yet... somehow, people still write code like they're saving bytes on a floppy disk.
Let me be clear: you're not in 1985 anymore. Stop acting like it.

I was inspired to write this after reviewing some open source js projects' code.

1. One-liners aren't genius — they're lazy

Nobody cares that you compressed an entire operation into one unreadable chain of functions. You're not proving intelligence; you're proving insecurity.
Readable code doesn't make you look dumb — it makes you look like you give a damn about the next person reading it.

Bad

const r = i.map(v => v.a).filter(Boolean).reduce((a,b)=>a+b,0)||null;
Enter fullscreen mode Exit fullscreen mode

Good

const amounts = items.map(item => item.amount);
const validAmounts = amounts.filter(Boolean);
const total = validAmounts.reduce((sum, amount) => sum + amount, 0) || null;
Enter fullscreen mode Exit fullscreen mode

The second version is clear, debuggable, and your teammate won't wish you'd never been born.

When one-liners are actually fine

Look, I'm not saying never use compact code. If it's a simple, obvious operation that fits naturally on one line, go for it:

const activeUsers = users.filter(user => user.isActive);
Enter fullscreen mode Exit fullscreen mode

That's fine. It's clear what's happening. But the moment you start chaining three operations with nested ternaries and abbreviated variables, you've crossed from "concise" to "hostile."

2. Braces are clarity, not clutter

"The less your code looks like line noise, the easier it is to maintain."
If you're skipping braces because you think it's "cleaner," it's not. It's just dangerous and ugly.

Bad

if (condition)
    do_this(), do_that();
Enter fullscreen mode Exit fullscreen mode

Good

if (condition) {
    do_this();
    do_that();
}
Enter fullscreen mode Exit fullscreen mode

Brace tells the readers: this is a unit of logic. Punctuation hacks just tell them you were in a hurry.

The hidden bug factory

Here's what happens in the real world:

if (user.isAdmin)
    grantAccess();
    logAccess(); // ← This ALWAYS runs. Oops.
Enter fullscreen mode Exit fullscreen mode

Without braces, that second line isn't part of the if block. But it looks like it is. Congratulations, you just shipped a security bug because you saved two characters.

3. Descriptive names are free — use them

It's 2025, not 1985. You're not fighting for every byte of memory. You have zero reason to name your function cntusr() instead of countActiveUsers().

Bad

function cntusr() {...}
Enter fullscreen mode Exit fullscreen mode

Good

function countActiveUsers() {...}
Enter fullscreen mode Exit fullscreen mode

Readable code is respectful code. Especially when you're not the only one who has to maintain it.

The "I'll remember what it means" fallacy

You won't. Trust me. You'll come back to your own code in three months and have absolutely no idea what proc_x_val does. Was it "process expected value"? "Procedure X validation"? "Proctor examination value"?
Who knows! Past you was too busy being clever to help future you.
As the saying goes, 2 weeks ago you wrote something that only you and God can understand and now only God knows what it means.

4. "Minimal syntax" is not "minimal thought"

There's a fetish in modern JavaScript for making everything shorter. Arrow functions inside ternaries inside object spreads inside template literals — it's madness.
Peak insanity:

const x = a?.map(v=>({...v,z:v.y?.[0]?.b?.c??d})).filter(v=>v.z)||[];
Enter fullscreen mode Exit fullscreen mode

You know what's actually minimal? A clear flow that doesn't make you stop every 3 seconds to remember what's happening.
Better:

const items = data || [];
const processedItems = items.map(item => {
    const value = item.nested?.[0]?.deep?.property ?? defaultValue;
    return { ...item, processedValue: value };
});
const validItems = processedItems.filter(item => item.processedValue);
Enter fullscreen mode Exit fullscreen mode

Yes, it's more lines. It's also maintainable by humans.

5. The Linux kernel is older than your ecosystem — and still cleaner

The Linux kernel has millions of lines of C code written over 30+ years by thousands of contributors worldwide. And you know what? It's more consistent and readable than most modern JavaScript repos with 200 contributors and a dozen maintainers.
That's what happens when you treat code quality like a religion, not an afterthought.
Linus doesn't accept garbage. And the kernel's coding standards document is required reading for contributors. The rules exist because they work.

What we can learn from kernel culture

  • Consistency matters more than personal preference. Pick a style. Enforce it. Move on.
  • Code reviews are sacred. Bad code doesn't get merged just because someone spent time on it.
  • Clarity beats cleverness. Every. Single. Time.

6. Code is read more than it's written

You'll read that same line hundreds of times — in code reviews, bug hunts, refactors, onboarding sessions, late-night debugging, production incidents.
Write like your future self's patience depends on it. Because it does.

The real cost of "clever" code

Let's do some math:

  • You save 30 seconds writing a one-liner instead of being explicit
  • Six months later, three different people spend 10 minutes each trying to understand it
  • That's 30 minutes of combined time wasted
  • Multiply by every "clever" line in your codebase

You're not saving time. You're time-shifting your laziness onto everyone else.

7. Your IDE isn't doing you favors if you're fighting it

Modern IDEs are incredible. Autocomplete, refactoring, inline docs, type inference. But all of that falls apart when you write:

const p = arr.map(x=>x.v).filter(y=>y>5);
Enter fullscreen mode Exit fullscreen mode

What's x? What's v? What's y? Your IDE doesn't know. TypeScript doesn't know. Your coworker doesn't know. Even you won't know in a week.
Write code that works with your tools, not against them:

const prices = products.map(product => product.price);
const expensiveItems = prices.filter(price => price > 5);
Enter fullscreen mode Exit fullscreen mode

Now your IDE can help you. Refactoring is safe. Types flow correctly. Everyone wins.

8. "But the compiler optimizes it anyway!"

Cool story. The compiler doesn't have to maintain your code. Humans do.
Even if your minifier turns everything into alphabet soup for production, that's not an excuse to write alphabet soup in your source. Your repo is for humans. The bundle is for machines.

The Wake-Up Call

If you've been writing code like this, here's the uncomfortable truth: you're not being clever. You're being selfish.
Every cryptic variable name is a middle finger to your teammates. Every unnecessary one-liner is time stolen from actual problem-solving. Every brace you skip is a bug waiting to happen.

How to Fix It

  1. Use real names. getUserById instead of getUser or getOneUser. totalPrice instead of tp.
  2. Always use braces. Even for one-liners. Especially for one-liners.
  3. One operation per line when dealing with complex logic.
  4. Write code for humans first. The machine will figure it out.
  5. When in doubt, be boring. Boring code is maintainable code.

TL;DR

  • Stop trying to be clever. Be clear.
  • Stop optimizing for character count. Optimize for human understanding.
  • Write code your future self will thank you for — not curse you over.

Your RAM isn't limited. Your storage isn't limited. Your colleagues' patience is.

Act accordingly.

Top comments (0)