Are utils (folder where you put random stuff you don’t know where to put otherwise) a code smell?

Personally, I love them. The way I think about is every function in that folder is npm package (or other package manager module) which was just never published.

Inspired by this article https://neilkakkar.com/things-I-learnt-from-a-senior-dev.html

Comments

[Fré Dumazy]

I don't like it. The worst is when you start working in an existing codebase that has this and you find yourself losing so much time finding these, or possibly recreating the same functions because you didn't know there's something for that.

However, structure is something that constantly evolves. If I don't know where to put something and don't want to end up in analysis paralysis, I might name the folder or file something like "reorganizethis-functions-for-feature-x". By applying constant refactoring these will find their way to a better place soon enough (mostly by the end of the day even).

[Avalander]

I think they are fine for functions that are too general or widely used to be included in another module and too small to warrant their own module.

Now, if half of the project files are inside the utils folder and are hundreds of lines long, maybe there's a better way to organize that.

[Mirroar]

For personal projects / tinkering, I'd say it's fine.

If it's more serious code, I think it warrants thinking about the design of every component, coming up with a good name, and having a place to put it. If you spend the time to structure your code well, you save others time when they work with your code.

Basically, I think of it this way: If I come into your project and don't know much about it, but I'm trying to find the source of a bug, I'll start by looking at the directories and files. If I find a file "PdfGenerator", I can pretty safely guess if it's relevant to my problem or not. If I find a file "PdfUtils", I'll be less certain what's in it, and might have to look at it more in depth. If I find a "HelperClass", I have no way of knowing what's in there and will have to look at the source to see if it's even relevant.

[Ilia]

GOOD point!! it reduces the code discoverability, now that you mention it I come to think that I felt that too. Yeah, I can imagine that if Utils gets very long and a lot of stuff is put into it, it's a sign of some spaghetti problem.

Come to think of it, in my view, Utils is something more of 'stdlib extensions'. Not some abstractions of your business logic code from all over the place which you didn't have a better judgement to put in the same domain with other business logic, but rather things you missed from your stdlib, something that cross cuts all functional areas of the your app and is more of a platform-needed invention, rather than your business differentiator invention.

[Shawon Ashraf]

Not always (unless as you mentioned, I have no idea what to do with those modules 😂). In many projects, I've placed helper functions / classes under utils since it was easier to do things that way without messing my head thinking of new names for a directory.

[Scott Simontis]

I have a repo of scripts and base classes for functional patterns. I just pick and choose what I need from the kit, I've seen far too many companies insist on putting the company Utility library in every project, only for it to get called twice or to realize no one even knows what it contains anymore.

[Ilia]

whole-company Utility library seems to be quite a departure from original simplicity of just Utils. If it's shared accross multiple projects, it sounds like it is an stdlib, and should be treated as such! (stable api, versioning, a lot of thoughts put into designing it, etc)

Utils in my view is project-specific and can be changed atomically within the whole project - you can decide to completely eliminate all Utils functions by inlining them everywhere - in a single commit.

[Abhinav Kulshreshtha]

I personally love Utils. Generally It's collection of functions which might be a utility for you, but not generalised enough to warrant a packaging. I also have a lots of wrappers in Utils. Think sop() instead of system.write.println() in java. or fetch() in javascript before there was actual JS fetch.

[Ilia]

I know right!!! Totally agree!

[Jonathan Law]

Definitely depends on the project size. I personally use them when I have a bunch of functions that can be grouped together and are used throughout the rest of the project, but I imagine on a bigger project (i.e. a project other people will see) it might not be the best idea

[Erick Navarro]

No, just an indicator that better organization is needed.

• Grab the utils file and put it inside the package were is used
• If it is used globally then assign its own package for it
• Do you need utils in the name? Most probably dont, is about text? text/Trimmer? text/Validations? text/Regex? text/Rules? Is it about files? file/InternalStorage? file/Writer? And so on and so on
• In some languages like in Kotlin or Js, yiu can choose, go simple with a functions file or actually scalate it to a class
• Add testing for it

[Ilia]

I don't really use namespaces, I kinda a fan of just making every exportable symbol in a project to be unique. Sometimes that means you have names which are slightly longer than appropriate, but I deem that an appropriate trade off against using packages in general, which are way more harder to manage/refactor.
So whatever would be in Utils would be global for me. Trimmer, Validations, Regex, Rules. Most likely it would be named TextTrimmer, TextValidations, TextValidationsRegex, TextValidationsRules etc, in order to avoid collisions with other symbols.
In my view, TextValidationsRegex would be quite possible to even publish as a package, even though it probably would be too opinionated for general use to actually do that, therefore it would just reside in Utils