Subscribe to RSSRefactoring – Stay Quick and Beautiful
This post has 206 words. Reading it will take approximately 1 minute.
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…
Recent Comments
2 Comments
at 14:57
Or simply:
return name + ‘(‘ + parameters + ‘)’;
at 15:01
True, though that relies on the compiler using the StringBuilder.