At my last job I met a software architect who, for a Flash project, jumped in and learned ActionScript in what must have been a few hours so he could work on the domain logic for a complex application. Just for background, I believe he primarily worked with .NET but you know how programming works… hours spent * natural ability = language independent skill.
Suffice to say he was indeed an extremely good coder and I’m grateful he spent some time passing on a few tips and tricks that apply to all languages, and some nice demonstrations using Haskell, ActionScript and of course C#. One such tip was the use of “pure functions” for example, which is always in the back of my mind now. (As a side note, I think learning a very different language like Haskell or in my case Ruby is a great way of keeping your mind open and it will help with your “daily” language).
Another of those tips went something like this: “hey, you know these switch statements, you can pretty much get rid of switch statements in an OO application using polymorphism”. For those a little unfamiliar with that term, in ActionScript this could be achieved by subclassing a superclass several times. This statement turns out to be, on the whole, true. A switch statement can a lot of the time be reflective of a problem in the architecture, a coupling of code, and by simply introducing interfaces and polymorphism into the equation you can refactor it down to maybe 2 lines from however many switch-cases. Overall there may be more code in separate classes, but it’s a lot more elegant, maintainable, extensible, readable, and most importantly, testable.
That brings me to the subject of this post. Making testable code is actually one of the best ways of writing *better* code. The Google Testing Blog has some of the best posts I’ve ever read on the subject of better coding. The latest post is on the very subject discussed in this post.
The Google Testing Blog.