loading...
Cover image for Clean code... Why bother? - Part 2

Clean code... Why bother? - Part 2

paulasantamaria profile image Paula Santamaría Updated on ・4 min read

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.

Posted on by:

paulasantamaria profile

Paula Santamaría

@paulasantamaria

Passionate about creating stuff. Gamer, digital artist and guitarist on my free time.

Discussion

markdown guide
 

a) How much more messy code I've written in my attempts at writing cleaner code, sometimes I tell myself that I should just do it the old way. Stop experimenting. Safer for the product and easier on my co-workers. But my experience is that in the long run it pays of to experiment. Try new approaches. Even on an existing project with already established patterns and rules.

 

I see what you mean. Sometimes when I'm having doubts about how to clean up my code I go to the language or framework official documentation. They usually have a section about good practices and all the code examples follow those practices. Like with C# Coding conventions.
Also, you may be interested in the book Clean Code: A Handbook of Agile Software Craftsmanship.

 

Good mini-series, Paula! Clean code is important, and I love how you've concluded it with real issues that hinder people from writing their best possible code. Shared both articles in our Telegram channel. 👉🏼 Link

 

That's awesome, thanks Utkarsh!