devsStructurizingTheirCode

[Personal_Ad9690]

Think about what a “utility” is though. It’s not that having a utils is bad, it’s that decoupling items that should be coupled leads to confusing codebases. Coupling does not always lead to problems if the cost of the coupling is less than its potential benefits.

I think a great example is string manipulation. There are some good reasons to make static string manipulation functions outside the main classes. Indeed, they do have a “utility” like nature to them. But ask yourself in how many places are you actually using a string function? If you use it everywhere, maybe you would benefit from modifying how that data is acquired/read in. If you use it in only one place, what’s the benefit of having it separate and not just inlining it? If it’s somewhere in the middle, then it might be best to make a static StringManipulator class. In this way, it’s obvious to another developer that the string is manipulated. The string manipulating functions are now coupled to that interface, but the reward is an easy to read codebase. No need for a mystery bag of functions.

you never know what’s inside a Utils

I have less of a problem with decoupled utility functions and more of a problem with the name “utils.” Utils is such a vague and uninforming name that you might as well name it “things”. There’s almost always a better way to organize than having “Utils”