Refactoring – Stay Quick and Beautiful

Sometimes you have to refactor something.  It may seem like it works, but the code is horrible-looking and inefficient.

Consider for example this gem:

No documentation, missing @Override annotation, quadratic blow-up of something that should be linear, unmotivated cloning of an immutable class, over-shadowing of field variables, leading to a clumsy syntax, and a code-structure that does not reveal the output…

I rewrote it to this:

We of course add JavaDoc referring to the defining class (ensuring a link in the generated documentation and a hint to IDEs they can just copy the old description), add an @Override annotation to prevent spelling mistakes, use a StringBuilder (a thread-unsafe and faster version of the old StringBuffer class) to reduce the execution time to linear in the number of parameters, abstain from cloning Strings (which are immutable), don’t use field-names for variable names, and reorder to adhere to the order of the output.

We also don’t reimplement toString for the collection parameters, as most collections have decent default implementations which means we don’t have to introduce a boolean variable in order to correctly add commas (or doing something as ugly as the original code, making a string comparison each time…

2 thoughts on “Refactoring – Stay Quick and Beautiful

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.