Cleaning House
There is something psychological about the environments you find yourself in throughout the day. Let’s say you are trying to study. We can probably all agree that a coffee shop and library are very different kinds of environments. Depending on the type of person you are, you might be able to study in a coffee shop but not a library, or maybe it is the opposite, or maybe you can study wherever! Either way, the environment you are in can either enable or prohibit your studying. This week’s post is going to explore messy vs clean code and how it can affect a project.
Clean Up Your Room!
We have all probably experienced a messy environment at some point in our lives: did anyone say messy room by chance? With a messy room, you can find things as you need them, maybe not efficiently, but you can find them. And hey, it might not be a pretty sight, but it works, for the most part.
Sometimes, the room gets to a point where it no longer works. You can’t find things, its hard to navigate, and oh god, it smells because there’s some hidden mac and cheese hidden somewhere! Cleaning your room will fix pretty much all of these problems and put you back in control of your room. You will know where to find things. It will be easy to walk through your room again and it looks good! Not only that, but you found and disposed of the moldy mac and cheese, so it no longer smells in your room too!
You can think of cleaning your room in two parts: throwing out junk you don’t need and reorganizing. When you throw out junk you don’t need such as receipts, wrappers, or moldy mac and cheese, your room’s appearance improves. When you reorganize things, you are putting things in logical places so that you’ll know where to find them in the future. To clean a room effectively you’ll have to do both these tasks.
Code Cleanup
Refactoring code can be thought of like cleaning up a messy room. At some point in a program’s lifespan, the code will go out of control to the point where you don’t even know what some things do anymore (even if you put in some really good comments)! Sometimes, even comments can’t help to explain the complexity of certain pieces of code. It’s very likely that someone just wanted to get a feature working and didn’t want to waste time making it efficient, so they just did whatever was necessary to make it functional (*cough* that certainly wasn’t me *end cough*). Now, you’re sitting here in the not-so-far future and wondering what the hell they could have possibly been thinking / trying to accomplish. You now have to clean up the messy code like you would your room.
Throwing out junk can be thought of removing unnecessary code segments such as certain variables, whitespace, or useless functions. Once you get rid of these, the code is shorter and easier to read. For Spotify Voice, I threw out extra API calls since Spotify recently updated their APIs to be more efficient. To reorganize code can be thought of as making code segments less logically complex. In Spotify Voice, a lot of my code was nested really deep. You can think of nested as being indented. So, with a lot of nesting, you can imagine code being very hard to follow and read. Notice the long vertical white line down the middle of the image below: that’s a good rule of thumb for how far indented code should go. As you can see, my old code was overshot that rule of thumb my a landslide:
To alleviate this issue, I used the fetch API which allowed me to rewrite (reorganize) my code to carry out the same actions as before, but without having as much nesting. I can now make logical sense of what the code does in a quick glance:
Another way to reorganize code is to create functions for repetitive code, so you can use the function in place of the repetitive code. In Spotify Voice, you might recall me talking about a token retrieval process when you first click “Login to Spotify”. This token is sent to Spotify’s servers every time you skip, pause, or like a song. In the code, I would manually type out the string of characters necessary to send this token every time: “Authorization: Bearer [your_token]”. Not only is this very error prone, but also repetitive, so I wrote a function to emit that string of characters every time instead. This made the code cleaner and more readable.
Until the Next Refactor
While refactoring (cleaning) code isn’t the most exciting of tasks, it is nonetheless an important one. Without being able to read code you previously wrote, there is no hope for improving it in the future. Too much time will be spent trying to decode your (or somebody else’s) thought process and logic: time that could be better spend being productive and adding new features! And I don’t know about you, messiness is not a pleasant sight. Cleanliness is significantly better looking and it makes sense! Just like after you clean a room, the more effort you put into maintaining this cleanliness, the less likely you’ll have do a cleaning marathon in the future.
Song of the Week
Werewolf by Quinn XCII feat. Yoshi Flower [Spotify][YouTube]
