How to explain to your colleages to stop creating packages and classes named “Utils”?

Question

In most of the projects at work it will eventually show up a package, a class (or multiple packages and classes) named "Utils", where every kind of function is dumped into.

It becomes excruciating harder and harder to navigate the project without a properly named structure. I have tried to ask to stop using "Utils".

When I find it if and the change to the codebase is small I normally refractor it and remove them, but they always end on showing up cluttering the code.

So do you know any strategy to make them stop doing this? Or am I just being a nagger?

Answer 1

Clean code is a valid concern. I like the Guava convention of using the plural form of a type, for example, Strings, Maps, and MoreExecutors. The main problem is that someone needs one or two methods that are related but feels a class needs more than that to warrant a separate class. This is the problematic assumption, and only a culture of frequent code reviews or quick hallway-design will catch it early.

One thing that can help also helps get others to use the utility method: demonstrate it to a few others when it's convenient. It may be enough to mention during a stand-up meeting, "Hey, I created a handy utility class for trimming and standardizing our usage of strings the other day. It's called Strings and is located in package com.example.type."

I will say that I'm less concerned with a package named util as long as there is just one. This is a catch all that should contain other packages that are application agnostic, i.e., a library. Some people call this package lib or tools, but I frown on plural package names (otherwise every package would end up plural).