Extreme Makeover: Code Edition

When I was in college, I took my first coding class. The class was specifically a creative coding for non-coders class. I learned HTML and CSS and then even forayed into classes on Processing (OO language for artsy people) and Arduino. I learned a little bit about a lot of things, but the thing I got really good at? Looking things up online. And you know what, my code may have been ugly, but it worked!

Today’s Project

My personal portfolio website was originally built of components copy/pasted code directly from w3schools. Did I know what that onClick event would do? Yes, in theory. Did I know how to write a line myself? Nope.

Fast forward to last week when I finished my 3rd module at Flatiron School, finishing up our section on vanilla Javascript. With that I decided to test myself to do some refactoring of my old code. Why?

  1. Looking at old code and being able to pull apart the sticky webs and find the source underneath it all is a really good skill
  2. I was embarrassed to have my old code out there, in the event someone did a little source code inspection (eep!)
  3. I’m a sucker for a good before/after. And that’s what we’ll be doing here

The purpose of this blog post is not to discourage you from writing ugly code. If anything, I want to encourage you to write lots of ugly code! And then, as you gain the skills, go back and continue to refactor it.

A Before and After (not quite as satisfying as a home DIY shot…)

Four screenshots of code, left side is the website’s original code, right side is the refactored code

How I refactored:

  1. Swapped out the inline Javascript. This allows for more flexibility as I can keep all of my event listeners in one place for easy review and editing. I also don’t need to copy/paste the same code multiple times on each of my webpages.
  2. Removed the iFrame. I structured my website with one “template” homepage, into which I would pass iFrame content to change the text content for each page. My iFrames didn’t pose a security risk, since I was controlling the content of the frame and nothing was being pulled in by an external domain; however, convention is really important in programming. It allows for universal standards so anyone can dive into any code and make sense of it. iFrames are conventionally used for things like ads, and by not sticking to convention, it made my code harder to read.
  3. Moved out the Javascript to a separate .js file. There are many reasons to do this. One of them is that the JS file will be cached, which reduces how much data needs to be transferred on each server request. Also, you may notice a theme here, but it’s cleaner and easier to debug.
  4. Don’t be a slob! You know how they say engineers don’t care about how things look? They’re lying. Engineers care VERY much about your code spacing and indentation. Organize those lines!

At the end of the day, my biggest lesson from this before/after? Keep your code readable! I dreaded diving back into this code just because I knew how disorganized it was. Can you imagine if a total stranger had to do it??



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