This week I’m taking a break from further cultivating my naive approach to create a Multi-factored Authentication system and do something I have always wanted to do for a long time — cleaning up and refactoring my old codes.
If you have just recently been through a coding Bootcamp like I did, you probably have a wonderful portfolio with multiple projects like me. Given the time constrain we had in Bootcamp(usually from 4 to 6 days) to complete a project while learning new technology, we can’t help but sometimes write fast and dirty code to put something on the table for presentation. The applications work like a champ but the codes can use some tidying up.
So how should we start cleaning up our own codes? There are multiple approaches to it. I personally like to follow the DRY, KISS principles. Aside from the linguistic implication, I like them for their easy-to-follow rules.
DRY stands for Don’t Repeat Yourself, a principle of software development formulated by Andy Hund and Dave Thomas, aimed at reducing the repetition of software patterns. It is stated as “Every piece of knowledge must have a single, unambiguous, authoritative representation within a system”. If you notice you’d have to type the same script in different places to serve the same purpose, consider abstracting that into a stand-alone function, or if you’re programming in OOP languages, find the similarity in both objects that uses that same block of codes and declare a class with that function encapsulated within. That way the code does not only look cleaner but also has less chance to break, and since the class itself has now become the single source of truth, you would save time writing unit tests to check for bugs as well.
KISS is a design principle populated by the N.S. Navy in 1960, which stands for Keep It Simple, Silly. The KISS principle states that most systems work best if they are kept simple rather than made complicated. Keeping your code simple can enhance readability as well as scalability. If you notice a function is doing multiple tasks, you might want to extract them into desperate functions and give them appropriate names.
There are also a few tips and tricks I learned online when I was looking for how to improve the quality of the codes, especially when you’re working in a team.
- Avoid ambiguous variable names
I’m guilty of this, I sometimes find myself typing “email” in one place and “email_address” in another, or when it comes to the input of a function, the name of the input sometimes would be shortened as function(a,b,c). The application would still work, but do you remember what are those a,b, and c for the function when you look at the code the next week when trying to expand some functionality? Chances are you would have to spend extra 30 minutes to an hour if not more to trace back where the function was called just to remember what type of data is being fed into the function. What about when another developer has to step in and read your code? Using meaningful naming conventions would help improve productivity and readability.
2. Limit the quantity of input
As the project scale-up, you might start noticing that the old function you wrote last week starts to need more information being passed in as arguments to render the perfect profile page for users. It will become problematic when a function accepts too many variables, it makes the function harder to test and difficult to debug. It’s really difficult for other developers to know the data needed for an argument especially when they started at where the function was called from, the amount of complexity is just too hot to handle. Try to limit the argument amount to no more than three, if it is necessary to pass in more than three arguments, consider grouping some of them into an object/hash before passing into the function so other developers can easily look at the constructor of the object/hash to figure out the needed data for the function.
3. Simplify the expression
Get familiar with the if else statement and utilize early return, especially for simple conditional statements. I stopped writing an else in my if statement if I’m only looking for one truth case from the two causes after I discovered the concept of the early return. Early return is when a function returns a value before the entire script of the function is proceeded, since returning a value stops the function, the rest of the script after the return line will not be run.
function returnBool(boolean){ if(boolean == true) return true; return false;}
So I can write my code like this instead of having an else statement. You can also further simplify the expression if you’re returning a boolean.
function canDrink(person){
return person.age >= 21;
}4. Scoping
Pretty sure everyone is familiar with the differences between var versus const and let syntax in JavaScript. If you don’t, var was the only way to declare a variable before ES6 syntax. Variables declared with var have a global scope, which means any user or function can access and rewrite its data from anywhere in the application, if not used carefully, data stored in var can be easily mishandled to have an unexpected outcome. Variables declare with const or let on the other hand would only be available to the current scope or lower. When you need a variable, declare from the lowest scope possible, and lift its scope only if necessary.
5. One task one function
Sometimes when you wanted to write code really fast, you might plant multiple tasks to be executed in one function. A couple of weeks later you wanted to have another checkout method and you only need the total, you see a function named “calculateShoppingCartTotal”, but you’re also getting an itemized receipt alongside the total when you called the function. 20 minutes later you found out somewhere early in the inner function it generates an itemized receipt for the cart for your general checkout. These types of things would be considered side effects and should be extracted to a different function so when we call a function it should do exactly what the name is specified.
Conclusion
I find these ideas really useful when it comes to writing clean code, especially for new coders like myself. The exact use of each tip and trick varies from case to case, but I believe it soon will become natural to me with practice. I’m gonna go into my code room to do some house keeping now, hope you find these tips useful as well.
