Code Refactoring — How to Write Better Code

Fionna Chan
3 min readOct 11, 2018
There are simply so much to learn in the programming world.

3 years into front-end web development, I am feeling as bad at coding as ever. There are simply so much to learn in the programming world so that a humble-enough developer would never dare to say his or her code is perfect.

I have been brushing up my CSS skills for the most part of my career, and that makes me lack confidence in my JavaScript skills for good reasons. Being a positive person who seeks growth all the time, I chose to turn this feeling of inadequacy into motivation instead of self-loath.

Below is a code test my fellow senior colleague drafted for the hiring process. He shared with other teammates so that we can give feedback on the efficiency of using this code test to determine the candidates’ programming skills. I took this opportunity to improve my JavaScript skills by dedicating the whole day to think about the code.

The Question

Write a function that when given a version number string, ie. “1.12.4” and a semver range string, ie. “~1.12.0”, return whether the given version falls within the given semver range as a boolean.

The semver range should support the three following patterns:
1) Exact match
2) ^ Versions greater in the same major version range
3) ~ Versions greater in the same minor version range

First Attempt

In the first attempt, I went for the easiest way to complete the task, using .substring(), switch case, for loops, and if conditions. Although the code looks ugly, it works, and it’s very simple to finish this solution because all these are the basics in JavaScript. My habit in coding is to make it work first, then refactor it until I am satisfied, and finally consider it as completed. It is probably not the best way for most people, but I am used to working in this way. (In the future, I would love to change the way I work and spend more time on thinking before starting to code.)

The code looks ugly, but at least it works.

Second Attempt

I know the switch case part and the if conditions are very ugly, so I tried to rewrite them. I wanted to find a function that can loop over the array in shouldMatch like .forEach() but one that I can break the loop when result === true so I googled and found .some() which is exactly what I wanted. I was rather ashamed that I didn’t remember this function, but I have forgiven myself. After all, there are functions that we don’t use often and it’s natural to forget them. My attitude is: use them more if you find them useful, and eventually you will remember them.

Now it looks slightly better. -13 lines. Not bad.

Third Attempt

I shared the code with the senior engineer, and he gave me some constructive feedback. He asked me to think of a better way to get rangeSymbol and try not to modify rangeNumArr after the declaration. Last but not least, he told me to use .every() , which is quite similar to .some() , but instead the loop would break when the return value is false. I took his advice and made some further changes, and it resulted in a beautiful piece of code:

-10 lines again! It has 23 less lines than the first attempt. INSANE.

Conclusion

It is very important to admit that you are not good at something, and seek improvement.

Ask for help if you need it. It is always good to have a different perspective because everyone has a different thinking process. Sometimes others’ opinions can inspire you!

Do not fear that you are wasting time on a simple function when you are doing coding exercise. Remember that programming is a creative process which consumes a fair amount of brain power when done right!

Applaud and follow me if you like this article!

I would share my front-end experiments and my thoughts on programming whenever I have time ;)

--

--

Fionna Chan

Frontend Unicorn. I 💖 CSS & JavaScript. My brain occasionally runs out of memory so I need to pen down my thoughts. ✨💻🦄🌈.y.at