Code Smells, written from a Frontend Development Perspective

So, I recently had this issue come up at work, and I wanted to talk about it in a little more depth. Do frontend developers need to adhere to basic coding practices, and can frontend code have “code smells”? A “Code Smell”, as defined in Wikipedia: “…is any symptom in the source code of a program that possibly indicates a deeper problem.”

Being that I originally came from backend coding and I was taught some of the basic ‘best practices’ of programming, I already apply many of these best practices in my frontend code, to avoid these code smells. But, we all make mistakes, and are often rushed to meet deadlines, and sometimes these issues are introduced into our codebases, either by accident or by ignorance. We are all human, after all! And, that is also, coincidently, why we have code reviews!

However, it seems that some of these ideas have not fully penetrated the frontend development industry. So, I thought I would take some time to talk about these “code smells”, and why they are not good practices, even for frontend code. Avoiding these code smells may be seen as common sense by some of you who have been around the industry for a while (learning either through classes, books or education, or through trial and error.) But, for novice and experts alike, it is good to be reminded of these concepts, so that we avoid the type of code that can ruin the maintainability and understandability of our codebases.

I have listed 5 of the more common code smells below, and also why they can cause issues with the upkeep of a healthy site. This list is written from a frontend developer’s point of view, since there are already many code smell lists with a backend programmer’s slant to them out on the web. Also, at the end of my short, high-level list, there are additional links to more full and comprehensive lists, so you can explore this topic more on your own.

Duplicated code

Frontend code affected: HTML, CSS, JS

The Issues:

Duplicated code is usually an issue for maintainability. The main problem with this code smell is if you have the same code block in multiple spots, and you have to make an update to one code block, you usually have to make the same update to all the code blocks that are duplicated. This is especially an issue if you have a developer that is new to a project, and he is not even aware of the other code blocks. If he doesn’t know they are there in the code, he will likely not update those other code blocks. Then the original issue that was being fixed or the code that was being updated, won’t be updated or fixed, in the additional blocks.

Duplicated code can also unnecessarily bloat your site’s codebase.

This code smell can also be an issue for readability, as it can cause confusion when reading the code, especially to a developer that is new to the code. The new developer will wonder about the purpose of the duplicated code.

There seems to have been a proliferation of this code smell in frontend development, in connection with adaptive sites, since it is possible to serve up the same structure of code to multiple devices. The issue is not readily apparent on the frontend of the site, when the code is parsed and served in the browser. But, low and behold, in the codebase, the duplicated code does exist, and is still an issue for maintenance.

How to avoid it or fix it:

If you find yourself using the same code in multiple places, try combining it and calling that one combined code block from each place that it is needed. In an adaptive site, use that same block of code for the devices that need it, instead of having a dedicated (but duplicated) blocks of code for each separate device. If there are differences for devices, add conditionals to account for them.

Pitfalls:

Don’t go too far the other way, and put in too many conditionals, or your code can become unreadable. There is a fine line to walk here, so maybe you and your team can define a specific percentage of code change that requires separate code blocks to be implemented.

Long and multi-use functions

Frontend code affected: JS

The issues:

When you find that you have a function that does almost everything for your site functionality, what could be called a “Master Function”, then you probably have an issue. Maintenance will be more difficult on a master function, because you will have to fully understand what everything in the function is doing to be able update or change the function, and have confidence your update will work and not cause additional issues.

Having a master function also works against the idea of code reusability. If the master function were broken down into smaller parts, you could probably reuse those parts in other functions.

You will probably also find that if you have a few “Master Functions”, that some of the contained functionality is duplicated (see duplicated code above.)

How to avoid it or fix it:

Try breaking up that master function into smaller functions, so that your code is more modular, more reusable, and more maintainable.

Pitfalls:

You can, inadvertently, go too far the other way, and have functions so small and abstract, that it is hard to understand their use.

Too many parameters passed to a function

Frontend code affected: JS

The issues:

If you have too many parameters being passed into a function, that function is probably doing too much, and you may have a master function (as mentioned above.) This issue adds to the complexity of the code, and causes issues with readability and understanding what the function is used for, or how it is used.

This code smell also could indicate a master function.

How to avoid it: Break down your function into smaller functions, each with a more singular task, so that you can make your code more modular, reusable and more easily maintained.

Pitfalls:

You could break down your function too far, and end up with multiple small functions that are too specialized and too abstract.

Multiple functions that do almost the same thing

Frontend code affected: JS

The issues:

This is really another code smell of the duplicated code issue, where you may have two functions that do almost the same thing, so there is a lot of code duplicated in each function.

How to avoid it or fix it:

Try to combine the two functions, normalizing the variables, and adding in conditional statements to deal with any differences.

Pitfalls:

If you go too far in the other direction with fixing this issue, you could actually create a master function (see long and multi-use functions.)

No comments or comments that are not useful

Frontend code affected: HTML, CSS, JS

The Issues:

This seems like a no brainer to anyone who has had code to work on, that they did not themselves, write. You cannot possibly know what was going through the original developer’s mind when they wrote the code, or the situation that prompted the code. Comments are a kind of map of the original developer’s thoughts while they were writing the code, comments that can help you understand the what, and more importantly, the why, of the code that you are about to work with.

How to avoid it or fix it:

The easiest way that I have found to make sure that I write useful comments, is to write the comments WHILE I write the code. If you make it a habit to write comments to explain why you are doing something, while you are writing the code, then you will always do it.

Pitfalls:

Writing too many comments can bloat your codebase, and your files, and can sometimes make the code harder to read, but, honestly, you have to write a LOT of unnecessary comments to get to that point! So don’t be afraid to add some comments!

Useful links about code smells: