Ditch Your Helpers and Utilities Classes Before They Ruin Your Code

15 May 2025 #misc

Recently, I needed to track down how an old Visual Basic WebForms app stored a value from the database into the Session object.

But I didn’t know I was in trouble until I looked for the file in the GitHub repository and it said “(Sorry about that, but we can’t show files that are this big right now.)”

The file had 69,359 lines. Its name? GlobalFunctions.vb. You can guess what was in there just by looking at that name, right? It was a clear symptom of a deeper problem.

The problem isn’t that it was a WebForms app in Visual Basic. It was that huge “throw everything under the carpet” kind-of file.

It reminded me of one of the conventions I decided to ban: “Helpers” and “Utility” classes, full of unrelated static methods.

If you’re tempted to write anything named with “Helpers,” “Utilities,” or worse, “GlobalFunctions,” please stop and consider how to split that class into smaller, more focused classes with clearer names. Smaller, well-named classes ease cognitive load, making them easier to work with.

Or even better, if you’re practicing DDD, before defaulting to a “Utility” class, ask yourself: does this belong inside an entity or value object instead?