Refactor It Ugly

Refactoring doesn't have to be to make the code prettier or more obvious. I suppose this little trick is obvious to everyone else, but I think it's useful even if I didn't do something original.

We had some code that already existed but needed some post-facto testing (don't get mad at me, it's not my fault. I came in late). We had other files that contained the expected results of an operation. Being familiar with testing, I started with the assert, and worked backward. Then I realised that there was a fair amount of duplication, and decided to do something about it even though the duplication wasn't a multi-line sequence. Maybe you'd not refactor a one-liner that repeats with different parameter, but it bugged me that the line was too long (more than 72 columns -- a travesty!!!).

I realized that the line was a function of its few different parameters, and that it really could be done non-redundantly. I wrote a small, simple, terse function to check the expected result. It was clear and pleasant enough for me. My pair didn't like it, since having all the condition expanded inline was "more clear" but I suppose the ambient noise was too loud in my head and I couldn't really hear him. I asked him to let me drive a little longer, and change it back if he hates the result. Having transformed seven different lines to use the simple function (and bring the line length under 72 columns) I, for one, thought it looked a lot better.

So we started to do the next test. We grabbed our expected results from another file, and started the task of transforming it by moving the parameters into the right order and removing punctuation we didn't need,turning it into a function call, etc. It was awful. If I had vim on his machine, I would have done it with a macro or with ed-mode commands, but here we were in Eclipse (which I like, by the way).

It dawned on me that it was easier to refactor the checking function to have its parameters in the *wrong* order than it was to repeatedly hand-transform the code. The refactoring tools would make it easy for me to "uglify" the code. It was a simple idea.

We changed the function signature to be "wrong" in the sense that it matched the order of the text we were using as input rather than having a more rational, programmer-friendly ordering of parameters.

Suddenly it became incredibly easy and quick to write a test, but a bit harder to read it. That is a great situation to be in as long as you are *writing* the code. We could even rename the function something unique but small and meaningless like xyx(). That makes it even easier to write the tests.

Once we're done, we refactor the signature, changing the function name and reordering the parameters to be easy to read instead of easy to write. If my partner still doesn't like it, he can inline all the invocations of the function. It's not hard in Eclipse, it will take a few seconds.

Sometimes it's easy to work with code that is temporarily ugly, since we can transform it back when we're not writing it.

!commentForm