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…
Or simply:
return name + ‘(‘ + parameters + ‘)’;
True, though that relies on the compiler using the StringBuilder.