Code cleanup tips to make your life easier

Sigh. Just spent all of Monday chasing down a CSS bug I 100% brought on myself. Turns out I reused the same class name on two different elements — classic case of sleep-deprived past me sabotaging future me.

Look, I’m not here to lecture about “code purity” or writing for the gods of open source. After more than a decade writing code — and watching pristine codebases slowly descend into chaos — I’ve learned that clean code isn’t about style points. It’s about saving yourself pain when you come back to fix or update things later.

So here are a few hard-earned lessons. No theory, no fluff — just stuff I’ve learned through trial, error, and way too much coffee.

Name Things Like a Normal Human Being Would

Okay, this is embarrassing—but here's actual code I wrote circa 2015:

const p = fetch('/api/products');
p.then(r => {
  if (r.ok) {
    r.json().then(d => {
      const f = d.filter(i => i.c === true);
      updateUI(f);
    });
  }
});

What does any of that mean? No idea. At the time, I thought I was being clever with short variable names. My team mates probably wanted to quit the project.

Here’s how I’d write that now:

const productsPromise = fetch('/api/products');
productsPromise.then(response => {
  if (response.ok) {
    response.json().then(products => {
      const featuredProducts = products.filter(item => item.isFeatured === true);
      updateProductGrid(featuredProducts);
    });
  }
});

Yes, it’s longer. But I can actually understand it now—especially when I’m exhausted, on a deadline, and wondering why the product grid is mysteriously empty.

Same Problem, Different Language: CSS

/* From my “I’m so clever” phase */
.cnt {
  display: flex;
}
.s-bar {
  width: 30%;
}
.m-cnt {
  width: 70%;
}
Now? I write:

/* From my “I don’t want to regret this later” phase */
.page-container {
  display: flex;
}
.sidebar {
  width: 30%;
}
.main-content {
  width: 70%;
}

Trust me : when a client emails at 4:30pm saying “can we move that THING a bit to the right?”, you’ll know exactly which “THING” they mean.

Pick a Style and Stick With It, Please

Last start-up I worked for, I was part of a six-person project. Within a week, I realized we had five different ways to do everything:

• Three totally different date formatting functions

• Tabs in some files, spaces in others (this started an actual argument)

• API errors handled differently in every component

My brain was fried just trying to remember how we were supposed to write code in any given file.

Let me save you the headache: pick something and stick with it.

I don’t even care what you pick. Just be consistent. Decide how you name files, write functions, format strings, handle errors—then do that everywhere.

I once spent a full day standardizing how we formatted prices. Here’s what I was dealing with:

// In ProductCard.jsx
function formatPrice(price) {
  return '$' + price.toFixed(2);
}

// In Cart.jsx
function formatCost(cost) {
  return '$' + Number(cost).toFixed(2);
}

// In Checkout.jsx
const formatTotal = (val) => `$${parseFloat(val).toFixed(2)}`;

Seriously? We’re all on the same team. Make a formatters.js file and use the same function. Then when the client inevitably says, “Can we switch to euros?”—you change one line.

Comments: Like Notes You Leave Your Future Tired Self

I used to think comments were for beginners. “My code is self-explanatory,” I’d proudly claim—while writing the most cryptic code imaginable.

Now? I write comments like I’m leaving instructions for myself after a long day. Because guess what? That’s exactly who will be maintaining it: me, but tired and annoyed.

/* Terrible or non-existent comment */
.header {
  margin-top: 267px;
}

/* Actually helpful comment */
// This margin aligns the header with the bottom of the hero image.
// If marketing changes the hero, this will break.
// Sorry in advance if you're fixing this at midnight.
.header {
  margin-top: 267px;
}

Some of my most useful comments start like:

• "This is not ideal, but..."

• "Caution: This will break if..."

• "Unusual edge case: Safari on iOS..."

Trust me—future you and your coworkers will thank you. Especially when we push a code in such a hurry, trust me something goes wrong somehwere. Atleast keep track of your quick-fix-midnight-work-around-aaah code.

One Component, One Job

Early in my career, I made these 800-line React components that did everything:

• Fetched data

• Handled forms and validation

• Processed payments

• Animated stuff

• Managed state

• Rendered every UI element

• Solved world peace

Then I’d wonder why I couldn’t reuse anything, or why a small change broke five unrelated things.

Now I use this checklist: If a component is doing more than 2–3 of these, I break it up.

• Data fetching → move to a hook
• Business logic → move to a service
• State management → context/store
• Complex UI → break into subcomponents

Smaller components = less stress, more reuse, faster debugging.

The "Where Does This Go?" Test

If I have to think for more than 5 seconds about where to put a piece of code, my folder structure is too complicated.

I inherited a project with all of these:

bash
Copy
Edit
/components
/pages
/utils
/hooks
/context
/services
/constants
/types
/styles
/assets
/lib
/helpers
/config
/api
/state
/wrappers

I once spent 10 minutes deciding where to put a phone number formatter. Helper? Util? Service? Library? WHY.

Now I keep it simple:

bash
Copy
Edit
/components
/hooks
/api
/utils
/assets
/styles

Done. If I hesitate about where something goes, I know I’ve over-engineered the structure.

Neither Too Clean Nor Too Messy

There’s a sweet spot between “it works but please don’t touch it” and “this code is so abstracted it belongs in a CS textbook.”

In my 20s, I wrote messy code that worked fast but caused long-term pain. Then I overcorrected and spent weeks building perfectly generic systems... for features that got scrapped a week later.

Now I aim for:

• Clean enough to debug easily

• Organized enough to onboard teammates

• Flexible enough for inevitable changes

• Not so over-engineered it takes forever to build

Do the basics well:

• Use meaningful names

• Break up giant components

• Add comments where needed

• Use TypeScript or proper types when it helps

And let go of solving problems you don’t actually have (yet).

Readable > Clever (Every Single Time)

I used to think writing compact, clever code meant I was a good developer.

// My "look how smart I am" code
const getFullName = data => ((data || {}).user || {}).profile ?
  `${data.user.profile.firstName || ''} ${data.user.profile.lastName || ''}`.trim() : '';

Now I’m team “just make it readable”:

const getFullName = (data) => {
  if (!data?.user?.profile) {
    return '';
  }

  const { firstName = '', lastName = '' } = data.user.profile;
  return `${firstName} ${lastName}`.trim();
};

It’s a few more lines, but I can actually understand it six months later on a Friday afternoon. That’s the real win.

Actual Results

This isn’t just about “clean code vibes.” These changes actually helped:

• New devs onboarded in days instead of weeks

• Average bug fix time dropped dramatically

• No one was scared to touch old code

• We stopped having "let's rewrite everything" meetings

Clean code saved us real time and money. We didn’t get smarter—we just stopped fighting our own codebase.

Baby Steps

You don’t need to refactor your whole codebase overnight. Just pick one thing and clean it up today:

• Rename cryptic variables

• Extract a reusable helper

• Add a few helpful comments

• Split a giant component

It adds up fast. Like compound interest for your sanity.