How To Avoid Reinventing Your Wheel with StringUtils

Ray’s Law of String Util Reinvention: “The probability of somebody creating a ‘Util’ class that contains common String manipulation methods is directly proportional to the number of people working on a project. When we have more than 3 developers, this probability is 100%.”

We’ve all been there haven’t we? After checking whether a String is blank one too many times, we decide to put this into a method and call it some unimaginative name, the most common of which is isEmpty. The most delightful occasion is when there are about 10 people working in the same project, and we have more than one StringUtils scattered in different packages doing roughly the same thing. Or one is StringUtil and the other is CommonUtil, but both have slightly different String manipulation methods.

Really, one shouldn’t anymore. Whenever you need something not included in JDK’s java.lang.String, your default action should be to go this existing, tested StringUtils implementation and check it out to see if it fits your needs. I’ve found that most of the time it does, unless the String manipulation is very domain/application-specific.

(UPDATE: Here’s a good example why you should not reinvent the wheel over and over again.)


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s