Why write clean code even when working alone on a project?

In my last project, there were several moments when my reactions were: "What??", "Do I need to do page1 or what?", "Why is this here?", "Oh, right, it’s for the header." And I think I’m not the only one who has had these kinds of reactions while coding.

Like many beginners in programming, I used to code quickly, without really thinking about the structure or cleanliness of the code. However, over time, I realized that writing clean code is the most important rule to follow, even when working alone. The problem often arises from thinking of clean code as something to do afterward. And honestly, that’s a big mistake. Dealing with poorly structured code later is like performing surgery without anesthesia. Why not start clean from the beginning? Why not make this rule a priority?

In my last project, a design inspired by Apple with features like GSAP and Locomotive Scroll, I realized that neglecting this rule could make things very complicated. The project was complex, with many concepts to handle, and without clean code, it became difficult to follow and debug effectively. So, what exactly is clean code? It’s not just code that looks pretty; it’s code that’s easy to understand, modify, and maintain. And trust me, it’s one of the keys to good collaboration, especially when we know that we spend a lot of time exchanging and modifying each other’s work.

Now that we understand why clean code matters, let's explore how to write it. I'll share some important practices, along with examples from my recent project, to show how I applied them in real situations.

1_Choose Clear and Consistent Names:

A clean code starts with clear, meaningful names for variables, functions, and classes. Instead of using generic names like data or temp, I learned to choose descriptive names that explain their purpose.

Example from my project:

• Instead of using a generic name like "tempPosition", I named a variable "headerScrollPosition" . It makes it immediately clear that this variable stores the scroll position of the header.

2_Don’t Repeat Yourself (DRY)

The DRY principle is one of the most essential rules to keep your code clean and maintainable. It means that you should avoid repeating the same code in multiple places. When I worked with GSAP for animations in my project, I noticed several animations that could be reused. I extracted them into reusable functions.

Example from my project:

• Instead of writing the same animation logic multiple times, I created a function animateElement() that I reused for different elements.

3_Separate Responsibilities

Clean code organizes different concerns into separate files or functions. This makes it easier to maintain and update specific parts of your project. In my case, I separated the scroll logic, animations, and page transitions into different files, keeping each responsibility clear.

Example from my project:

• I had a file scrollHandler.js for managing all scroll-related functions and another file animations.js for handling animations.

4_Keep It Simple

It’s easy to overcomplicate code by adding unnecessary complexity. But clean code is simple and straightforward. Avoid adding extra layers unless they’re necessary. In my project, I made sure that the logic was as simple as possible and didn’t add unnecessary complexity for features that weren’t critical.

Example from my project:

• Instead of overcomplicating the scroll effect with excessive conditions, I kept it simple, focusing on the essential behavior.

5_Limit Comments

While comments are helpful, clean code should be mostly self-explanatory. If you’re writing too many comments, it could mean that the code itself needs improvement. I made sure that the code in my project spoke for itself, using meaningful names and breaking it into logical functions so that comments weren’t needed unless explaining complex logic.

Example from my project:

• Instead of commenting on every line, I used clear function and variable names to reduce the need for explanations.

Conclusion

In summary, You should always write clean code because, in the end, the person who will have to revisit and understand it might be you. Even when working on personal projects, there will come a time when you need to look back at the code. You might face a problem and recall solving it in that project, only to find that you can't remember what you did or why. Clean code ensures that future you won’t struggle to understand past you.