Last week I wrote about how minimalism can help you keep your code clean, but as I was writing I realized that something was missing. Writing clean code is nice and all but it also takes hard work and sometimes you have to spend extra time to get it right, so why bother? Why is it so important?
In this article I'll go through 6 of the reasons why I believe clean code is important and worth your time!
1. Your teammates will thank you
If you've ever worked in a team with many devs you know that sometimes you need to modify or fix a feature coded by someone else. Isn't it great when that code is nice and clean? ✨
Working in a team is a wonderful thing. You get to share knowledge and passions with other people and there's always lots of learning involved. But when it comes to code we all have our ways and we probably approach problems differently. Clean code makes it easier for your coworkers to understand your approach.
2. Think about your future self
So, what if I work alone? Or what if I hate my coworkers and I want to see them suffer? 😂
Clean code is not valuable only for your team, but for your future self as well! It may be you who has to modify or fix some old feature developed by yourself. And believe me, you will be equally (or even more) happy to have nice and understandable code written by yourself to work with.
3. Messy code tends to get messier
Once you approach a solution ignoring clean code practices and just throwing anything that works in, there's no going back without refactoring the whole code. You may have to leave it there to move on to the next feature and avoid delays, sure. But eventually you'll have to go back to fix some bugs or modify something, and then you'll be faced with two options:
- Spend some extra time refactoring the old code
- Keep working in the mess 🐷
If you go with the first option you'll solve the issue, but you'll get delayed, and your team probably can't afford the delay. That's why messy code tends to get messier. You'll be forced to go with the second option and make the mess even worst again and again until someone decides that taking the first option is worth the delay (which may never happen).
Wouldn't it have been better to write clean code in the first place?
Also, the messier your code becomes, the harder it gets to get it cleaned up. Messy code could corrode your project little by little until it ruins it entirely.
4. Faster decision making
When you're following clean code principles it's easier to make decisions like:
- How should I name this property?
- What comment style should I use?
That's because clean code is based in standards and conventions that define a bunch of stuff so you don't have to!
Every mayor programming language has its own set of standards and conventions defined by their creators and communities that exist to make everyone's life a little easier. I highly recommend looking up those conventions for every programming language you use.
Here are a few:
- C# coding conventions
- Google's Javascript style guide
- Kotlin coding conventions
- Python Style Guide (link provided by @yucer)
If you work with Javascript also check out ESLint!
5. Reduce repeated code
Writing clean code means following naming conventions (among other things). These conventions help you choose descriptive names for your classes, variables, functions, etc. Even files need to be correctly named!
When all your code has descriptive and intuitive names it's easier to find what you're looking for. Need a way to get all unread messages? Try MessageService.GetUnread(). You'll have a hard time find it if the method it's called ArrayOfUnreadMessages() instead.
Bad naming could lead to:
- Best case scenario: Wasted time searching for stuff.
- Worst case scenario: Repeated code with a different name: You couldn't find
ArrayOfUnreadMessages(), so you createdUnreadArray(). They both do the same thing, and they both have horrible names.
6. It feels great!
You know that feeling when you clean up your desk and everything is where it needs to be, and you just want to take a pic and upload it to whatever social media you use? Well, that's how writing clean code feels like. Try it 💪!
Why do you think writing clean code is important?
Tell me in the comments! 👇
Top comments (38)
I kind of disagree on point 3. So far in every company I worked for, in the first phase we always write a quick and messy poc to see if our idea is indeed achievable. Once the second phase gets approved, I always had the opportunity to refactor it properly. In rare cases when the pic is an insane mess, I was always aloud to start from scratch. No one willingly wants to write shit code.
As long as you set the expectation that version 0 is intended to be thrown away from day 1, this works.
If on day 120 the team figures out this unspoken assumption isn't shared, things fall apart.
Hi Stefanos, thanks for your comment!
To be honest, I never worked in a company that followed that kind of process. I don't doubt it works for you and your team. But, in my opinion, writing a fast POC and using clean code principles are two things that can easily coexist whitout interfering with one another. Once you know naming your functions correctly is important, why would you do otherwise? How would that speed up the process?
The third point is specially important when you work with beginner devs in the same team. After all, every code you leave for them to work with serves as example. Checkout the broken windows theory (mentioned by @eidsonator in another comment).
You have a point on naming. But naming is the least of the problems and by far the easier to amend. I was referring about concepts like SOLID principles, well thought abstractions, patterns etc
I see what you mean. I suppose is about balancing between good and clean practices and simple enough implementations.
You're lucky! Most places I've worked see a POC and want to rush to the next step.
That's why it's important for us as developers to manage up. We need to advocate for some extra time to do POCs the right way because it most likely become production code
The only complains I have from our process is that a. the poc allocated time spans between 2 to 4 weeks in order to decide whether a ~2 years project is feasible... b. between the poc and the actual start of the project there is barely enough time to properly design it. Thus following certain practises as the article suggests is highly recommended
As of lately though things have improved by a lot.
Just wanted to state a counter-argument here, and say that point #3 resonated with me more than any other.
I am currently refactoring a code base for a client that is outrageously messy. And why? Because the original developer was messy and the people that followed him just copied his style. Now we have huge functions, one of them 1400+ lines long.
I guess I should not complain. They are paying me very well to clean it up.
Thank you. This is really a great post. I am in total agreement. Clean code requires more of your time and thought process at the beginning but it makes up for avoiding a wind world full of headaches and time wasters.
Thank you!
Better naming the identifiers is one of the harder tasks
It would be good to research more about how that affects the understanding of the code.
For example giving negated names for boolean variables like: no_update
When negating that it would be:
if not no_update then...
It would be better:
if update then..
For me, name booleans with question identifiers. Like "is updated" or "hasBeenUpdated". Then you get code like "if(hasBeenUpdated)" and it makes more sense linguistically. However, if you work with members who aren't super fluent in English it becomes tough, because English is totally a tricky language.
I try to do this as well, makes it easier to read.
This is the case where you'd really scratch your head when encountered.
Clean code and architecture always leave me thinking, how far should we go for it?
I've had cases where a team member obsessed with this would make it really hard for everyone else to follow up the flow of an app.
I find this topic annoying at times. Because we are all different and hardly agree on what "done" is or what "clean" is.
I now let the definition of what the "product" decide on how I should proceed.
Once that product has a clear understanding of what is required, then experience follows with what the appropriate architecture looks like, thus the tech, the principals and standards that should follow.
How about ensuring a one function one thing (sounds familiar 😏) principal which will allow for easier changes or modifications as the "product" evolves.
And if there is more than one
ifin your function STOP!...Last thought... If we actually took time "to measure twice and cut once" we would spend less time refractoring and bug fixing.
🤓😅
Another great article on clean code, and one I agree with in its entirety.
One of the rules I try to follow is the 'boy scout rule'. Every time I check out and make a change to some code I always check it back in cleaner.
I think one of the most important things for clean code is a good set of unit tests with code coverage. That way you can clean to your heart's content without worrying about introducing breaking changes.
You're absolutely right. I try to always go through my changes before commiting to verify that everything is nice and clean. Haven't thought about it before, but I guess I follow the 'girl scout rule' myself 😂
Faster decision making - I did't notice this advantage until now, thank you. By the way, it is only one advantage at this list which is important for non-developers, especially for management. So I have an incentive to expand this list from the business point of view. I stay tuned.
An article about clean code from the business point of view sounds truly interesting, I'll definitely stay tuned!
Thank you, Gerard!
This is a really great framing of the topic.
Thank you, Ben!
I once refactored numerous lines of code and it gave me a headache (figuratively) and I did a git annotation there, I was surprised -- it was my code 2 years earlier when I first wrote them.
Writing clean code is not the first step of your career as software engineer.
I like the idea behind this post.
That said, in general, code sucks as a medium for informal reasoning (the kind of reasoning where you try to understand something's behaviour by observing it). On top of that, our tools (text editors, CLI programs, version control systems) are heavily code oriented which makes changing the status quo pretty hard.
The best we can achieve is either:
These days when developing JavaScript I like to use XState for generating (✨ interactive!) graphs from my code. The benefit of such graphs is being able to understand how stuff work before adding features / making changes, and thereby avoiding common pitfalls that become obvious as soon as you look at the visualized graph, but are easy to miss with just code alone.