Is it an anti-pattern or code smell to put "general use" functions (examples below) into a catch-all file named "helpers" or "utils"?
undefined, constructing a URL from a struct of parameters, transforming strings in some fashion, etc, etc.
I often come across applications or libraries with one (or more!)
helpers.ts files which just seem to be, in my opinion, a dumping ground for unrelated functions. In my opinion, code is more readable and discoverable if it's named semantically.
If working with the examples above, I'd place them all in their own files (
url-builder.ts, etc), or if they are related functionality, group them (eg,
clone.js or similar).
I struggle to articulate why this seems like a code smell or anti-pattern to me. I think there are various things at play: creating the wrong abstraction or abstracting at the wrong time (YAGNI) meaning code is just dumped "somewhere", lack of foresight for future maintainability.
On the other hand, I've seen proponents of this pattern argue that it's a well-used pattern, and thus it has merit simply because it's well-used. Does this argument stand?
Interesting in anyone's thoughts on this, whether you think it's good or bad, and if you can explain the pros/cons better than I can!