How much code can be re-used?

Had it ever happened to you that you started to work on a new project and you needed a piece of functionality that you knew you had written in previous project? You just wished that you had all good pieces of your code in your own shared library. Then it would just be a matter of a simple utility method call.

I was recently put on a project that was at its final development stages. I was asked to write unit tests for “util” package, which was probably the only part that could be tested in isolation. So I wrote the tests, tried to cover at least 80% (my comfort zone) of reasonably testable code and raised few questions that discovered some hidden bugs or deficiencies. All was going well, but there was a method that got my attention. Actually, it was not the method itself, but rather its JavaDoc comment. Method was named replaceStr and took three String parameters: str, pattern, and replace. The comment simply stated that “This is quicker/simpler than using String.replaceAll().”

This was not the case of re-use, but re-invent. I was not quite convinced that this method would perform any better than String.replaceAll() as I could not see this being supported by any test or other way of proof. So I decided to write a little test. The test was far from ideal, but it would do to prove to me that the new method had a valid reason. So I wrote a code to randomly generate about 2000 variable length Strings and to run about a hundred various replacements using String.replaceAll() and this new method and at the end to compare the times of execution.

Surprisingly, I had some troubles with String.replaceAll() due its usage of regular expressions, where I had to remove the subset of characters to run the tests on. Another surprise arrived when I finally ran the tests. The custom implementation proved to be almost twice as fast. “Well done,” I thought. Now I was convinced with my little test that this method surely is faster. I still was not sure how or if it would behave correctly for extreme cases, but due time constrains I had to move on.

And then I again I came to re-usability of the code. Surely, some one must have written some a method that does exactly this and have tested it. My first stop was at Jakarta Commons projects. And there it was. There was a StringUtils class under Lang project. I quickly downloaded the library, included the library in the project and wrote few lines to run the same test using this class. In most cases the execution time was equal or a bit more than of the custom code.

I believe that is a good reason for using this library rather than spending time and effort developing the same but different “wheel”. Sure, you can ask “Is it worth to include whole library just for one method call?” Probably not. Brief look at the library lead me to the discovery of many other useful methods that could be used in this project. The other things to consider are deployment constrains. Sometime you are required to write a custom code and to include no or as little third-party libraries as possible.

The conclusion: Get familiar with Java API. There are lots of things that are worth knowing and using. If you don't find the functionality you need and must implement it, check first if some of the free or open-source libraries doe not have it already. Most of the times, they do and the code it well tested, documented and maintained.