Pyntheus Programmers

If you enjoy this article, support us!

Introduction

In this series, Pyntheus Programmers aim to give you a treasure trove of tips, delivered to you in “byte”-sized chunks (see what I did there?) to help you write less “smelly” code.

Before I dive into this section, let me start with a quiz question: what do argon, salt and code have in common? Do you give up?

Answer: they’re all odourless!

So, what am I talking about when I say that I’m going to give you tips to write less smelly code, if code is already odourless? Well, I’m using the term “smelly” as a metaphor in this section, not in the literal sense. I define a code smell as anything which is technically correct in our code and won’t have any impact on our code functioning, but they are symptomatic of poor design choices.

Why Should I Care?

“But my code runs fine! All this talk of code smells is for you fancy-schmancy top-hat wearing elitists! I don’t need to waste my time on this!” I hear you say. Well, let me try to change your mind and convince you just why you should pay attention:

Firstly, I don’t wear a top-hat.
Secondly, let me introduce you to the term “technical debt”. This refers to the situation – which I’m sure we’ve all been in before – in which we choose an easy (and often lazy) solution when writing our code today, which costs us a vastly larger amount of time in future. In my experience, and I’m sure in the experience of many other programmers out there, taking a few extra minutes to make the hard choices today can save us weeks of time down the road.
Thirdly – whilst the code you’ve written might make total sense to you, what if you’re not the only person to ever read it? In the real-world, most code is worked on in a collaborative effort by a team. Ensuring your code is well-structured goes a long way to ensuring readability and maintainability by others – I can promise you that your team will thank you for it (disclaimer: I am not legally liable for any lack of thanks you get from your boss, colleagues, significant other, kids, or stranger that you once held a door open for).
Finally, even if you don’t work in a team – I’d also urge you to consider yourself at some time in the future as a different person (no, I’m not referring to some profound personal growth you’ll go through, although of course, I’d love to see everyone around me grow and develop). The code you’ve written today may make sense to you – but a year down the line and 100 other scripts later, will you confidently be able to revisit this script, be able to fully understand it quickly and be able to update it in accordance with the changing needs of your project?

“You’ve convinced me, maybe well-written code isn’t just for you city-slickers, maybe it is worth investing the time upfront” I hear you say. Great! In that case, let’s dive into our series of posts to help improve your code. The tips and tricks I discuss will be based on a combination of my own experience writing code, reviewing code on behalf of my colleagues and various books and resources I’ve come across along my programming journey.

As a little present for you staying until the end – here’s a picture of a cute dog, alongside my poor attempt to give it some sort of relevant context to my post: it’s said that dogs possess a sense of smell that’s up to 10,000 better than human, with the ability to smell just about everything from cancer to hormone changes relating to emotions. Perhaps with some training, I’ll be able to teach a dog to smell bad code one day, but that’ll be for a separate blog series … stay tuned.

If you enjoy this article, support us!

946 views