In my latest article I wrote about clean code and why it's worth your time. As I was writing it, I kept coming up with ideas but it was getting too long, so I decided to leave some for a second article.

I'll begin with more reasons why I believe clean code is worth your time, and also talk about some of the obstacles we may find on the path of writing cleaner code.

1. Clean code leads to better practices

When you're trying to clean up some code, you may realize the reason your code is messy is because there's a bigger issue that needs taking care of.

For example: I realize my code is not clean because the name I'm giving to the function is not intuitive: UpdateUserAndGetRemoved. And as I'm thinking a better name for the function I realize the problem is that I shouldn't have a single function that updates the user and returns the removed users, because functions should have a single purpose. So, in this example, I should have two functions, Update and GetRemoved.

2. Reviewing PRs is hard work

Pull Requests reviewers have to read your changes line by line to understand what they do and to decide if your solution fits their needs appropriately. This takes a lot of work and messy code just makes it harder. The reviewer may add some comments for you to fix or they may even decide its not worth their time and just reject the whole PR.

Keep in mind that messy code not only affects you, but may be making someone else's work unnecessarily complicated.

3. Reusability

Better practices mean more reusability. Going back to our example in #1: The messy and badly named function UpdateUserAndGetRemoved is less reusable than the split version Update and GetRemoved.

Reusability helps us avoid repeated code and keep the behavior of our software consistent. And it also contributes to build new features faster by reusing code that was written for a previous feature.

Also, reused code is usually safer, because it was probably already tested along with the original feature it was written for.

4. Faster bug fixing

When you're assigned a bug to fix, the first thing you need to do is to understand the error, and then the code that provokes it. Clean code should be easier to fix because it's easier to read and understand. You may read it and find the error right away without even having to debug it.

Messy code will probably force you to debug over and over, and you'll even realize you'll have to rewrite a lot of it to fix the issue.

This is one of the reasons why code readability is key.

Some final thoughts

As most good practices, clean code is an investment. You may need to spend a bit of extra time writing it, but you’ll definitely enjoy its benefits later.
More importantly, the investment doesn’t only benefit the project, but also you: applying good practices helps us learn and become better developers.

There may be obstacles

Telling you that all my code is always 100% clean would be a lie. I'm an advocate for good practices and I always try my best to apply them, but there are certain factors that prevent our code to be as clean as we'd like. Some examples:

a. We are constantly learning

As we learn and improve, our code tends to get better, specially if you're trying to write cleaner code. That means that if we look to past projects we're probably going to find some not-so-clean code, and that's ok. We simply can't get better at coding without coding.

b. Frameworks evolve, good practices change.

As frameworks evolve and new features are available, the best way to solve a problem using said framework may change as well. That means your old code may contain bad practices that weren't bad at the time you wrote it.

The best example I can think of is the introduction of async/await to Javascript. Before this expressions were available, we had to use nested callbacks or promises to execute asynchronous code, which is much messier in comparison (there's a reason why people call it callback hell).

c. We simply can’t afford it

Writing perfectly clean code takes time and sometimes we can't afford it.

All of these are perfectly valid and, most importantly, real issues. But, should I give up on writing clean code just because it'll never be perfect? Of course not! It's not our responsibility to write perfect code all the time, but it definitely is our responsibility to try our best. That's my opinion anyway.

Don't have enough time for perfectly clean code? Compromise! Do your best. It'll definitely be better than giving up entirely. Invest in your project and yourself.