Beginner’s Guide to Refactoring in JavaScript

When you’re first starting out in your coding journey, building a web page/application seems so far out of reach. When you finally feel ready to create you very first app, your main priority is just getting the darn thing to work. You slab functions wherever they seem like they fit and your naming conventions are probably not that descriptive. But at the end of it all…it works!

After finishing your victory lap, it’s important to make it a habit to walk around that lap again but this time, taking a good look at everything. What does your code look like? How long are your functions? Is there any repeated code? These are good questions to ask to start the process of refactoring.

Refactoring

Refactoring is the act of dismantling and re-assembling your code in an effort to make it more readable and functional. Some questions to ask when deciding if a function needs to be refactored are:

1. Is this function over 5 lines long?

2. Does this function do more than one thing?

3. Does the name of this function poorly describe the purpose of it? Another way to ask this is if someone else was reviewing my code, would they have trouble knowing what the function should do based on the name alone?

4. Is there anything within my code that I did twice?

If the answer for any of these questions is “yes”, it’s time to refactor your code!

Functions more than 5 lines long & completing more than one task

If your function is more than 5–7 lines long, find ways to break it up into multiple functions.

The function above is a typical example of being too long. Refactored it could look like:

Now that there are two different functions, the code is much more readable. Within the

showTotalExpenses

function, there is everything that appeared after line 200 of the original function. By calling it at the end of

sumExpenses(user)

Javascript will run that code immediately after line 200, meaning nothing was truly changed by splitting the two up. It just looks and reads much better!

If you look closely in the original code you can also see that the first half of the function is working to add up all the expenses while the second half is working to append the result onto the page. Because there are two different goals being fulfilled, it’s better to break them up (even if the function was less than 5 lines long).

Is your function adequately named?

Above, we see a function named

clearExpenses

However, if we really look at it, we can see that the function doesn’t actually clear anything. What it really does is provide a “Clear Expenses” option for users on the front end. Therefore, it would be better if our function looked like:

With this, we named our function

clearExpensesOption

then called a function named

clearExpensesEvent

at the end which will deal with the actual clearing of expenses itself.

Is there anything within the file that I did twice?

If the answer to this is yes, consider creating a function / variable and calling it whenever it is needed, rather than writing the same code / string multiple times.

Finishing Thoughts

By doing all of these things, you not only help people who will be looking/working with your code, but your future self. You will now know what each piece of code will entail before even looking through it because your functions are better broken down and named.