Code Refactoring | S01E01: The Chanel Principle

Part I of the series “Code Makeover”

There are many reasons to refactor your code. It might be for better performance, more readability, improved maintenance and scalability, you name it. So, ready to check one of the easiest ways to start refactoring?

Today we’ll focus on what I’m calling the Chanel principle.

The Chanel Principle

Before you leave the house, look in the mirror and take one thing off.
— Coco Chanel

There are lots of trinkets that make our code hard to read. So, before you commit your work, look at your code and take one thing off. Which kind of things can you remove, though?

Let’s suppose you’re working with this API to create a brief astronaut profile. Below is the JSON you receive from the API. From here, you need to extract: 1) Astronaut’s name; 2) Astronaut’s spacecraft; 3) Astronaut’s agency; 4) Astronaut’s working status. Your front-end expects to receive all this data in an object format. How would you write your function?

As an exercise, try to write your own function before peeking into mine :)

Image for post
Image for post

One possible solution would be this:

Image for post
Image for post

Declaring variables for everything can seem helpful when you are processing data but… is it really necessary?

1. Take off unnecessary variable declarations

So let’s follow Chanel’s advice and take one thing off? In this case, you can well skip all the variable declarations and go straight to the object. Note that this will also reduce the number of arguments passed to your function:

Image for post
Image for post

2. Take off verbosity

However, the profile function above can still be enhanced. Have you noticed that the object values are a bit long and wordy? So let’s keep “Chanelling.

Image for post
Image for post

Wait, but you just said not to declare unnecessary variables, and yet you just created one! Why?

In the first example, we got rid of variables and reduced our code, but refactoring is not necessarily about reducing your code, it’s about making it clear. When we added the variable astronaut, this one line gave us a much better code later. It may sound picky right now, but when you start working with more complex data, verbosity can become a nightmare.

3. For the strong at heart: Destructure

What about getting all your variables in one go?
This post from Maya Shavin is everything you need to know about destructuring, don’t miss it!

Image for post
Image for post

Important: If destructuring (or any sort of refactoring, for that matter) works only to show how clever you are, it’s best not to use it. I bet Chanel would say that being humble is pure elegance.

A real-life example

I’ll show you how lame my code was and how beautiful it became after my colleague Oli, a poet in refactoring, paired up with me.

I had this big JSON, and, much like in the example for the astronaut, I only needed a few bits from it. I’ll share it in full just so you have an idea of what real life payloads are made of. The data itself is fake, but I’ve kept the structure untouched.

This was the code I wrote originally:

Image for post
Image for post

And this is how it ended up after pairing with Oli:

Image for post
Image for post

Can you see what happened?

We ended up with the same number of lines, but the last version is way more readable — and elegant.

Stay tuned for more tips in refactoring :)

My friend Bukola has also written about refactoring, check it out ;)

Written by

Journalist turned techie. Talks about coding in real life | DevSecOps Engineer & School of Code alumna | Birmingham, UK

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store