loading...
Cover image for Clean code... Why bother?

Clean code... Why bother?

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

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:

  1. Spend some extra time refactoring the old code
  2. 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.

Ross geller from friends in the messy apartment feels something on his back and gets scared

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:

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 created UnreadArray(). 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! 👇

Discussion

pic
Editor guide
Collapse
elasticrash profile image
Stefanos Kouroupis

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.

Collapse
morgenpeschke profile image
Morgen Peschke

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.

Collapse
paulasantamaria profile image
Paula Santamaría Author

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).

Collapse
elasticrash profile image
Stefanos Kouroupis

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

Thread Thread
paulasantamaria profile image
Paula Santamaría Author

I see what you mean. I suppose is about balancing between good and clean practices and simple enough implementations.

Collapse
ehorodyski profile image
Eric Horodyski

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

Collapse
elasticrash profile image
Stefanos Kouroupis

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.

Collapse
mikeschinkel profile image
Mike Schinkel

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.

Collapse
rconr007 profile image
rconr007

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.

Collapse
paulasantamaria profile image
Collapse
yucer profile image
yucer

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..

Collapse
ehorodyski profile image
Eric Horodyski

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.

Collapse
paulasantamaria profile image
Paula Santamaría Author

I try to do this as well, makes it easier to read.

Collapse
sshanzel profile image
Hansel Solevilla

This is the case where you'd really scratch your head when encountered.

Collapse
okbrown profile image
Orlando Brown

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 if in 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.

🤓😅

Collapse
davjvo profile image
Davmi Jose Valdez Ogando

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.

Collapse
pedrootero profile image
Pedro Otero Prada

Then it's not clean code

Collapse
davjvo profile image
Davmi Jose Valdez Ogando

That's where I wanted to get sorry for not being clear.

Sometimes we got so deep in architecture rules, conventions, our own environment limitations. That we forget about clean coding.

Collapse
jeastham1993 profile image
James Eastham

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.

Collapse
paulasantamaria profile image
Paula Santamaría Author

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 😂

Collapse
gjaryczewski profile image
Gerard Jaryczewski

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.

Collapse
paulasantamaria profile image
Paula Santamaría Author

An article about clean code from the business point of view sounds truly interesting, I'll definitely stay tuned!
Thank you, Gerard!

Collapse
ben profile image
Ben Halpern

This is a really great framing of the topic.

Collapse
paulasantamaria profile image
Collapse
ejrojasb profile image
EmilioJRB

Great post. I totally agree on every point.
The time it takes to do clean coding is the time you are saving others or even yourself to modify the funtions or scaling them. And not only that, it even helps you seeing the purpose even faster and look for flaws and alternatives.
I think is a "must" and not a "could"

Collapse
thesigitprayoga profile image
Sigit Prayoga

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.

Collapse
amitnovick profile image
Amit Novick

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:

  1. Write code that is supposedly easier to understand
  2. Use code only as a low-level source for generating other artifacts which we can understand more easily: e.g. state machines or statecharts (images not my own).

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.

Collapse
dzoeller profile image
Dan Zoeller

The only legitimate reason on that list IMO is #6. No one is going to thank you for clean code. Eventually, you will be out of the picture and someone is going to rush around to add a feature and the code base will get messy, they will start naming things however they want to. So do it because it feels good and you know it's right :)

Collapse
paulasantamaria profile image
Paula Santamaría Author

For me, the #6 summarizes all the others in a way. I do it because it feels great to take advantage of all these other things.
I do code reviews and PR reviews regularly and I do feel thankful every time I have to review clean code 😂
Altough, your comment made me think that I should actually say "thank you" to the dev more often.

Collapse
eidsonator profile image
Todd Eidson

Great article. I'd always heard number 3 associated with the "broken windows theory". That's a good subject to read up on, if you haven't already.

Collapse
paulasantamaria profile image
Paula Santamaría Author

I remember watching a documentary about it but I'd completely forgotten the name of the theory. Thank you Todd!

Collapse
yucer profile image
yucer

You can add python code conventions:

python.org/dev/peps/pep-0008/

I like also the tools that verify the code against those community standards (linters)

Collapse
paulasantamaria profile image
Collapse
nilshochschwender profile image
NilsHochschwender

Btw function calls are expensive

Collapse
lukegarrigan profile image
Luke Garrigan

Love it, couldn't agree more! This blog was just the inspiration I needed to get my sh*t together and clean up an old feature I'd botched together. Thank you! 🤗.

Collapse
paulasantamaria profile image
Collapse
alexandis profile image
alexandis

Bravo, perfecto!! :-D

Collapse
byrro profile image
Renato Byrro

Quick note: first link at the top of the article is broken.

Collapse
paulasantamaria profile image
Paula Santamaría Author

Nice catch, thank you!