If sci-fi and fantasy has taught us anything, it’s that we should never judge anything by its size.  In fact, there’s even a geeky principle called The Bishonen Line which is:

…the tendency of monster creatures (especially evil ones) to become big and disfigured as they increase their power, then suddenly shrink back down to human proportions. This can be used to indicate that the character has reached a point where he has “full control” of his powers, and therefore can access them selectively — taking the ass-kicking abilities while leaving the giant-scary-monster abilities.

In development, we call taking huge, disfigured and monstrous code and shrinking back down to human size, “refactoring.”  “Refactoring” is a fancy-sounding term that often means “redoing,” and the point of it is to make big, ugly code into smaller, readable code.

So, if we take the Bishonen Line as our principle, our goal when refactoring should be to give the code “full control” of its powers, allowing it to do the ass-kicking without the whole scary-monster thing.

This runs counter to the assumption made by inexperienced development managers (and some inexperienced coders, as well) that writing lots of lines of code is the sign of a proficient and/or hard-working developer.  If you’re spending time reading a blog about software development, you probably already know that lines-of-code is a crap metric, so I won’t belabor the point, except to say that I’m the most proud of the changes I’ve made where I’ve eliminated 1000 lines of code in a single check-in.

Realistically, a method or class will start with one well-defined purpose, then have some additional, kind of related functionality added into it, have a bunch of assumptions made that later turn out to not always be true, be forced to call into methods only to jump back out because they aren’t relevant for this particular processing, allocate some memory that never gets used (or freed), throw an exception and catch it in the same method, and then return an error code.

Good developers end up with horrifically mutated code that looks like this all the time, and they refactor it when they have the chance.  Bad developers end up with horrifically mutated code that looks like this all the time, and don’t even recognize this is a problem to be fixed.

There are many different methods (some links to which I’ve listed below) that can be used to refactor code to make it more readable, maintainable and smaller (but not usually to make it more efficient, although this can be a goal of refactoring), but there are some things that one should specifically be careful of:

1. Resist “clever” hacks. Making the code smaller is only one of the goals of refactoring.  If to refactor the code you have to introduce something like Duff’s Device (outside the context of an embedded system or a really hot loop), you’re probably not really improving things. Situations will vary, of course, but learn to sanity-check yourself if you start to feel yourself grinning uncontrollably at your own cleverness.
2. Use automated refactoring tools carefully. The right-click action “Extract Method…” in Microsoft Visual Studio is very adept at creating methods with tons of parameters.  It can analyze the block you’re asking it to extract and determine which are the free variables that would need to be passed as parameters and often what the return value(s) of the method should be, but it can easily be used to create methods that no sane developer would write from scratch.  Use it and similar automated methods carefully.
3. Avoid adding lots of parameters to new methods. You want to minimize the amount of data that each method has to operate on, but if each new method you introduce during refactoring takes everything as a parameter to it, you won’t have any guarantee that the method won’t use or manipulate data inside of one of the values passed to it.  One of the goals of refactoring is to reduce the number of parameters that a method takes, and give access to data only inside of the methods that manipulate it.
4. Don’t break conventions lightly. If you have a convention that’s followed throughout your code, don’t break it so you can refactor some code in one module or class.  Maybe the convention is bad and needs to be changed everywhere.  Honestly, if you have conventions that people actually follow consistently, you should consider yourself to be quite lucky.
5. Avoid confusing people. If something is a part of the language that’s rarely used or that many people have trouble understanding, be sure to comment the code well.  For example, lots of folks have trouble understanding the new functional programming constructs that are in C# 3.5, not because they’re slow or stupid, but just because they haven’t been exposed to functional programming before.  These new features are great for making code more compact and possibly even more efficient, but you need to make sure that the people you’re working with understand what the hell you’re doing.

If you’re interested in some techniques for refactoring (things you should try to do when refactoring), here are some links:

• Alphabetic List of Refactoring Techniques
  (by Martin Fowler, the author of Refactoring: Improving the Design of Existing Code)
• Refactoring C++ Code
• Database Refactoring (from an “Agile” perspective)

Refactoring is something that takes time, to be sure, but it pays dividends down the road, and you shouldn’t let the opportunity to spend some time cleaning up your code pass you by.

P.S. When used by itself, the word “bishonen” means, uh, something slightly different.

August 19th, 2008 | Tags: automation, functional programming, hacks, refactoring | Subscribe to comments | Leave a comment | Trackback URL