Have you ever stared into a utility folder teeming with countless files? Or perhaps you've tried updating a seemingly simple utility function, only to watch it trigger a cascade of errors across your program? What about encountering a utility function bloated with a dozen if-else conditions, or one that's, ironically, only imported by a single file?
Here is a fairy tale.
In a small group of developers, they were creating a very simple product.
They had to process and validate the data in the streaming process.
So, they created a useful function and placed it in a folder mysteriously named Utility.
As time passed, the data source's interface was updated.
The development team could easily update the function.
Everything looks good.
Now, as the team grew, they had many services that could reuse this function. They have a few options now. They chained functional calls together, resembling a long cargo train. And so, another new function found its way into the Utility folder.
Everything looks good.
As the team grew, more and more unrelated functions, some with subtle business logic, were added to the Utility folder. Some utilities started calling other utilities, creating long, hard-to-follow chains. The once-simple utility function for data processing now had flags and conditions to handle many new, slightly different use cases, making it bloated and confusing.
Moreover, now you can't find a thin line separating between each domain. You may see some weird import from Shopping Cart in Authentication domain.
A new developer joined the team and had to debug some code. He quickly started debugging but soon found himself lost in a tangled web of utility calls, struggling to trace the logic.
Why people often create a utility folder?
First, they might want to follow the DRY principle. What is DRY principle?
DRY is an abbreviation for "Don't Repeat Yourself," a principle that advises against writing the same code multiple times.
These principles are often discussed in the context of Clean Code, such as in Robert C. Martin's book 'Clean Code: A Handbook of Agile Software Craftsmanship'. Book
Secondly, and often as a direct result of adhering to DRY, functions in utility folders are easily reusable across various parts of a project.
Thirdly, developers might create utility functions to isolate specific pieces of logic, which can simplify unit testing.
It seems to have a valid reason to have Utility in your project.
Is a Utility folder bad?
While the intention behind utility folders is often good, aiming for principles like DRY and reusability, the reality can be different if care isn't taken. A well-organized set of specific utility modules could theoretically contribute to cohesion within those modules, but a generic catch-all utility folder often becomes a problem.
We must consider these topics before putting it in Utility.
- Is that code generic?
- Is that code used multiple places?
- Does the code contain business logic?
- Will adding this to a shared utility folder actually make the overall codebase more complex to understand or maintain?
Utility folders themselves aren't inherently bad.
However, populating them without careful consideration is what cultivates a detrimental coding habit.
Failing to ask these questions before adding to a utility folder is what often leads to the bad habit of creating a disorganized 'junk drawer' that complicates your codebase, as seen in our fairy tale.
What are your experiences with utility folders? Share your thoughts in the comments!
Top comments (0)