Blog

No more “helpers”, please

Arjan Molenaar

Arjan Molenaar

Updated August 19, 2026
2 minutes

Naming is one of the hardest problems in software engineering. This applies to functions, classes, and even packages.

Almost every project I’ve seen over the past years has it: a “helpers” or “utils” package. Without exception, this package is a collection of random bits and pieces, a grab bag: some string functions, a simple parser for whatever, generic data structures.

How do you recognise a helper package? Well, by its name for one. Secondly, it contains random pieces of functionality. Many packages in your application use something from it.

There is no such thing as a helper package, a helper class, or a helper function! Every line of code serves a purpose. If it doesn’t, just get rid of it. If you take a closer look at the pile of code in your “helpers” package, you’ll find that each piece of functionality is only used from one place. Why not move the functionality to that package?

A classic example is Java’s java.util.ArrayList class. This class represents a collection, yet the java.util package ends up as an incoherent mixture of functionality. What is a list doing in a package next to calendars and Base64 encoders? Scala and Kotlin do a better job and put those data structures in a collections package.

What to do instead

Instead of collecting random bits of code in a "helpers" package, look at where each piece of code is actually used and move it over there. If it's code that is used in several places, it may be that you missed a concept in your application. If the code deserves its own package, give the package a name that reflects what the code actually does.

As a rule: if you can't name the package without using words like "util", "helper", or "common", the package boundary is wrong.

Closing thoughts

Naming is hard. Using generic packages named like “utils”, or “helper” does not help. They turn out to attract random bits of code and become a mess themselves. Think about the name, the purpose of a class or function and put it in a package that expresses said purpose. No more “helpers”, please!

Written by

Arjan Molenaar

Contact

Let’s discuss how we can support your journey.