What is bad code? One thing to make your code better instantly

Humberto Bernabé
3 min readMar 19, 2020

--

Is my code bad?

Is my code bad?

Are you doing everything to write good code? What is even good code?

There are many good and valid opionions and standpoints out there that define what is good code and what is bad code.

Code should be readable, maintainable and reusable and much more. Wether our code fulfills these principles relies on many details. For example there is a big bunch of coders that heavily advocate the use of comments in their code.

And there are many good reasons to use comments in your code. And in my eyes, the absolute number one reason is :

If you see/edit code 1 month later, comments may help you to memorize your logic that you have written while writing that code.

I dont know how many times if ran into the issue where i was writing code that i couldnt decipher anymore just a few weeks later.

Its not only a problem at an enterprise level, where you have to work with other people and read their code but also it is something that will even affect you when you just write your own projects.

But contrary to the devotees of commenting everything there is this saying that you might have heard before.

“Good code is self-documenting.”

There is definitely some truth to this. There is code that you can read and understand almost immedialtley what it does and what you need to to do change it and is one of the things that distinguishes a seasoned coder from a newbie. This would be the goal of clean code.

There are already alot of books and blog posts about clean code out there but i want to speak about one thing that i think matters more the people give it credit for.

Naming things right!

You can save yourself (re)writing alot of code if you just name your things right.

A simple example that might open your eyes would be:

Lets say you have a simple function that adds a month to a date.

function add(date, month) {
// ...
}

const date = new Date();


add(date, 1);

As you write this you know what it does and everything is fine right?

But would you know 1 month later? Maybe not.

Something better to write would be:

function addToDate(date, month) {
// ...
}

const date = new Date();


addToDate(date, 1);

as it is more descriptive and clearer.

We did it, right?

Not quite. Because it doesnt say anywhere that we are adding a month to a date.

function addMonthToDate(month, date) {
// ...
}

const date = new Date();
addMonthToDate(1, date);

Much better. Its clear what to function does and there is no need to comment at all because we can just read the function declaration and know whats up.

Of course, something very important is that, the function shouldn't contain any code that does anything else than what we described, like in this case anything but adding the month to the date. It shouldn’t have any side effects.

Conclusion

This is an easy example and in reality things are often more complicated.

My advice is to rather spend a little bit more time on naming than youd like to, just to get really the best result and give your code added clarity and not only for yourself but also your future self.

--

--

Humberto Bernabé
Humberto Bernabé

Written by Humberto Bernabé

Software developer that uses a pen.

No responses yet