Clean code... Why bother? (2 Part Series)
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!
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.
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.
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.
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
- Kotlin coding conventions
- Python Style Guide (link provided by @yucer)
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
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 created
UnreadArray(). They both do the same thing, and they both have horrible names.
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 💪!
Tell me in the comments! 👇
One of the most consolidated misconceptions about programming, since the early days, is the idea that such activity is purely technical, completely exact in nature, like Math and Physics. Computation is exact, but programming is not.