You’re not a caveperson, so please write clean code

For me, as a frontend developer with my background, communication skills are gold. In any workplace. And writing clean code is a way to show off these amazing skills, as well as to become a better teammate. We’ll come to that, but first, I want to share a bit on what makes code cleaner, as I just started reading an enlightening book by Robert C. Martin, Clean Code: A Handbook of Agile Software Craftsmanship: over 400 pages you won’t read in a day, but I bet it will be worth it!

What is clean code?

Clean code isn’t only to write as few lines as possible, even if clean code should indeed be concise: it’s more about writing code in a way that the next human reading it will understand the code and be able to use/fix/refactor it somehow easily.

It doesn’t mean one should add comments everywhere, on the contrary! Clean code is self-explanatory, with meaningful names for functions, components, variables, etc.

In this example, the styled component, variable and function bear unclear names:

But here, it’s a bit more understandable:

There’s more to it than being descriptive, for example a developer who cares about clean code (and we all should!) needs to use adequate names for less confusion (recipePage should not be the choice for a page with multiple recipes, recipesPagewould then be more suitable), to have functions as small as possible and with only one purpose, to be consistent, to remove commented out code, to keep the code DRY, etc. I’ll stop here, because there are more than 400 pages of this in Martin’s book, and many summaries can be found with a bit of googling.

Why is clean code important?

Yes, it can take more time when first writing your code to do it clean, because, of course, it’s faster to write c than isCodeClean! But writing new code is only a small part of a developer’s day. Most of it is dedicated to fixing code, reviewing code, refactoring code, etc. And for all these tasks we need to read code. Clean code enhances the productivity when doing all these “read-then-write” tasks.

However it’s not the productivity I wanted to bring here. It’s more the human side of clean code.

In his book, Robert C. Martin writes about the fact that clean code is written by someone who cares. Writing clean code is a way to show that you respect your coworkers, value their time as well as yours. It allows you to communicate properly what your code is, what it means to do, and in return allows others to understand it and work with it with more efficiency and pleasure. Starting to work on a clean codebase should inspire you to write clean code as well, because you can see the benefits. Of course I use some shortcut, but in the end, it makes you a better teammate.

Martin uses a wise analogy in Chapter 1 of his book:

“A building with broken windows looks like nobody cares about it. So other people stop caring. They allow more windows to become broken. Eventually they actively break them. They despoil the facade with graffiti and allow garbage to collect. One broken window starts the process toward decay.”

So who here wants to read code written by a teammate who doesn’t care? And who wants to work on a codebase on the verge to decay?

(…)

That’s what I thought ;)