Naming convention for utility classes in Java

Question

Like many such conventions, what's important is not so much what convention you use, as that you use it consistently. Like, if you have three utility classes and you call them CustomerUtil, ProductUtils, and StoreUtility, other people trying to use your classes are going to constantly get confused and type CustomerUtils by mistake, have to look it up, curse you a few times, etc. (I heard a lecture on consistency once where the speaker put up a slide showing an outline of his speech with three main points, labeled "1", "2nd", and "C".)

Never ever ever make two names that differ only in some subtlety of spelling, like having a CustomerUtil and a CustomerUtility. If there was a good reason to make two classes, then there must be something different about them, and the name should at least give us a clue what that difference is. If one contains utility functions related to name and address and the other contains utility functions related to orders, then call them CustomerNameAndAddressUtil and CustomerOrderUtil or some such. I regularly go nuts when I see meaningless subtle differences in names. Like just yesterday I was working on a program that had three fields for freight costs, named "freight", "freightcost", and "frght". I had to study the code to figure out what the difference between them was.

There is no standard rule/convention in Java world for this. However, I prefer adding "s" at the end of Class name as @colinD has mentioned.

That seems pretty standard to what Master java API Designer Josh Bloch does ( java collection as well as google collection)

As long as Helper and Util goes, I will call something a Helper when it has APIs that help to achieve a specific functionality of a package ( considering a package as to implement a module); mean while a Util may be called in any context.

For example in an application related to bank accounts, all number specific utility static APIs would go to org.mycompany.util.Numbers

All "Account" specific business rule helping APIs would go to

org.mycompany.account.AccountHelper

After all, it is a matter of providing better documentation and cleaner code.

I like the convention of just adding "s" to the type name when the type is an interface or a class you don't control. Examples of that in the JDK include Collections and Executors. It's also the convention used in Google Collections.

When you're dealing with a class you have control over, I'd say utility methods belong on the class itself generally.

I think that 'utils' should be the package name. The class names should specify the purpose of the logic inside it. Adding the sufix -util(s) is redundant.

I'm pretty sure the words "helpers" and "utilities" are used interchangeably. Anyway judging by the examples you provided, I'd say if your classname is an abbreviation (or has abbreviations in it like "DomUtil") then call your package "whatever.WhateverUtil" (or Utils if there's more than one utility in your package). Else if it has a full name instead of an abbreviation, then call it "whatever.WhateverUtilities".

It's really up to you, but so long as coders know what you're talking about, you're good-to-go. If you're doing this professionally as a job for somebody though, ask them what their coding standards are before taking my advice. Always go with the shop standards no matter what as that will help you keep your job. :-)