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

twitter logo github logo ・1 min read

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

twitter logo DISCUSS (12)
markdown guide

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.


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

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


I would need to see what precisely was in the utility folder to know it was a code smell. I've seen instances where it was, and where it was not. The greater danger in my experience is the bad habits in invites developers to adopt, i.e., not thinking about the structure of the code they introduce.


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.


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.


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.


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.


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.


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.


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

Classic DEV Post from Dec 31 '18

Dealing with copyright infringement and plagiarism

This is a story all about how my life got twisted upside down, and I'd like to ...

Ilia profile image

Hey there reader...

Do you prefer sans serif over serif?
