Class names should be nouns, in mixed case with the first letter of each internal word capitalized. Try to keep your class names simple and descriptive. Use whole words-avoid acronyms and abbreviations (unless the abbreviation is much more widely used than the long form, such as URL or HTML).
A utility class is a class that is just a namespace for functions. No instances of it can exist, and all its members are static. For example, java. lang. Math and java.
Variables should be named using camelCasing. Variable names should always start with a lower case letter. Packages should be named using snake_casing. Package names should always start with a lower case letter.
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. :-)
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With