DEV Community

Cover image for 🚫 Stop Using These Bad Coding Habits (Your Future Self Will Thank You)
Darshan Raval
Darshan Raval

Posted on

🚫 Stop Using These Bad Coding Habits (Your Future Self Will Thank You)

#ai #webdev #programming #productivity

Writing code is easy.
Writing code that your future self (or your teammates) won't hate is the real challenge.

Every developer starts with bad coding habits.

The problem isn't having them.

The problem is keeping them.

After reviewing countless repositories, working on production systems, fixing legacy code, and spending hours debugging simple mistakes, I've noticed the same habits appearing again and again.

Here are the biggest coding habits you should stop today.

1. ❌ Naming Variables Like a, x, temp, data

Bad:

const d = getData();
const x = d.filter((i) => i.active);
Enter fullscreen mode Exit fullscreen mode

Better:

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

Good variable names reduce the need for comments.

If someone needs to guess what a variable means...

...the name isn't good enough.

2. ❌ Writing Massive Functions

If your function takes two minutes to read...

It's too big.

Bad:

function processOrder() {
    // 250+ lines
}
Enter fullscreen mode Exit fullscreen mode

Better:

validateOrder();
calculatePrice();
processPayment();
sendConfirmation();
Enter fullscreen mode Exit fullscreen mode

Small functions are easier to:

  • Read
  • Test
  • Debug
  • Reuse

3. ❌ Copy-Pasting Code Everywhere

We've all done it.

Ctrl + C
Ctrl + V
Ctrl + C
Ctrl + V
Enter fullscreen mode Exit fullscreen mode

Then one bug appears...

Now you have to fix it in 12 different places.

Instead:

  • Create utility functions
  • Extract reusable components
  • Follow the DRY principle

4. ❌ Ignoring Error Handling

Bad:

const user = await getUser(id);
Enter fullscreen mode Exit fullscreen mode

Better:

try {
    const user = await getUser(id);
} catch (error) {
    console.error(error);
}
Enter fullscreen mode Exit fullscreen mode

Production code always fails eventually.

Prepare for it.

5. ❌ Writing Comments for Obvious Code

Bad:

// Increment i
i++;
Enter fullscreen mode Exit fullscreen mode

Good comments explain WHY, not WHAT.

Example:

// Retry because payment gateways occasionally timeout.
Enter fullscreen mode Exit fullscreen mode

That's useful.

6. ❌ Hardcoding Everything

Bad:

const API_URL = "https://example.com/api";
Enter fullscreen mode Exit fullscreen mode

Better:

const API_URL = process.env.API_URL;
Enter fullscreen mode Exit fullscreen mode

Future deployments become much easier.

7. ❌ Never Refactoring

If your code works...

Great.

That doesn't mean it's good.

Every feature leaves technical debt.

Take time to clean it.

Future developers (including future you) will appreciate it.

8. ❌ Deep Nested Conditions

Bad:

if (user) {
    if (user.isVerified) {
        if (user.subscription) {
            if (user.subscription.active) {
                // do something
            }
        }
    }
}
Enter fullscreen mode Exit fullscreen mode

Better:

if (!user) return;

if (!user.isVerified) return;

if (!user.subscription?.active) return;

doSomething();
Enter fullscreen mode Exit fullscreen mode

Early returns make code dramatically easier to read.

9. ❌ Not Using a Linter or Formatter

Formatting manually wastes time.

Use tools like:

  • ESLint
  • Prettier

Consistency matters more than personal preference.

10. ❌ Skipping Tests Because "It Works"

"It works on my machine."

Every developer has said it.

Every developer has regretted it.

Even a few unit tests can prevent hours of debugging later.

Bonus Habit

❌ Not Reading Your Own Code

After writing a feature...

Close the editor.

Take a short break.

Come back 20 minutes later.

Read your code as if someone else wrote it.

You'll be surprised how many improvements you'll notice.

Remember

Clean code isn't about impressing other developers.

It's about making life easier for:

  • Your teammates
  • Your future self
  • Anyone who has to maintain your code

Programming isn't just about making computers understand.

It's about making humans understand.

💬 What Bad Habit Did You Finally Break?

I'd love to hear from other developers.

👇 What's one coding habit you stopped doing that made the biggest difference?

Let's help each other write better code.

✨ Thanks for Reading!

If this article helped you become a better developer—even by 1%—then it was worth writing.

Let's keep learning, building, and growing together. 🚀

— Darshan Raval

Technology Lead • Full Stack Developer • Node.js & System Design Enthusiast

"Code is read far more often than it is written."

❤️ See you in the next post!

#javascript #node #webdev #programming #beginners #softwareengineering #coding

Top comments (15)

Collapse
 
algorhymer profile image
algorhymer •
  1. ❌ Naming Variables Like a, x, temp, data

Let's do a check list:

  • No variables, since it is not supported.
  • No mention of arguments at all.

Yup. I aced it.

extrapolate :: [Int] -> Int
extrapolate = sum . foldl' (flip (scanl (-))) []
Enter fullscreen mode Exit fullscreen mode

Fàilte gu Alba!

heh

Btw, below is a pic of our famous military hero Lance Corporal Cruachan IV with his trusty human servant on his side:

lance-corporal-cruachan-iv

Collapse
 
darshanraval profile image
Darshan Raval •

Modern problems require functional solutions! Can't have bad variable names if you don't use variables at all.

Collapse
 
ayushh profile image
Ayush Sharma •

Python?

Collapse
 
algorhymer profile image
algorhymer •

Dutch?! Ewwwww... nonono. Scottish, Glasgow :)

Collapse
 
kartik-nvjk profile image
Kartik N V J K •

The naming and giant-function points matter even more now that a lot of code is machine-generated, because a model reuses whatever conventions it sees and single-letter names propagate fast. The one I would push hardest is the error handling, since a swallowed exception is the kind of failure that stays silent until it corrupts something downstream. Worth pairing these with a linter so the habit is enforced rather than remembered.

Collapse
 
darshanraval profile image
Darshan Raval •

100% agreed! The point about AI propagating bad naming habits fast is so true. Also, swallowed exceptions are definitely the worst offender here. Automating these checks with a linter is a great takeaway to keep the codebase clean without the cognitive load.

Collapse
 
ayushh profile image
Ayush Sharma •

hahaha I'm the one who doing this, I will not do this silly mistakes. thank you for this blog.

Collapse
 
darshanraval profile image
Darshan Raval •

Welcome

Collapse
 
fugofresh profile image
FugoFresh •

Good

Collapse
 
darshanraval profile image
Darshan Raval •

thanks

Collapse
 
mia_keller_ffd2584c046ecb profile image
Mia Keller •

This is a fantastic checklist, and point #8 on nested conditions is a total game-changer—early returns completely rescue code from the 'pyramid of doom' and make it instantly readable. I also love the bonus habit of walking away and reading your own code with fresh eyes. It is amazing how a simple 20-minute coffee break can suddenly make you look at your own logic like a stranger who desperately needs a friendly code review!

Collapse
 
darshanraval profile image
Darshan Raval •

Thanks, Mia! Glad those points resonated with you. You nailed it nothing humbles a developer faster than looking at their own code after a 20-minute coffee break and wondering, "Who let this person near a keyboard?" 😂 Escaping the 'Pyramid of Doom' is honestly one of the best gifts we can give our future selves (and our teammates). Thanks for reading and sharing your thoughts!

View full discussion (15 comments)

Some comments may only be visible to logged-in visitors. Sign in to view all comments.