Refactoring
by C. Keith Ray
Software development on your project has slowed to a crawl. Instead of
adding new features, you and your fellow programmers want to rewrite
the existing code to make it easy to work with again, which of course
frightens product marketing and your boss. How do we get into these
messes? What can we do about it?
Many books and courses teach principles, rules, and guidelines of good
design, but somehow much of the code we write still exhibits traits of
poor design, and poor design slows us down.
Code smells are one such trait of poor design. I will illustrate
several code smells, using real working code from the Mozilla project,
to show you how you can clean up your design by using small refactoring
steps. Then you will be able to identify some of the symptoms of poor
design and understand how it can be incrementally improved.
I've chosen the Mozilla project because it is open source, has a
large code base, and was written over an extended period of time by
people of varying skill levels. It is working code, delivered to
end-users as the Firefox Web browser, the Thunderbird email client, and
various components, libraries, and other applications. I am not a
Mozilla developer, so I am viewing the code with fresh eyes.
Instead of reproducing the actual C++ code from the Mozilla project, I
will translate it into pseudo-code to make it more compact and to let
us ignore various C++ idioms and issues of syntax.
I'm going to start with the code example in Figure 1: the method
GetTextHelper in the class nsAccessibleText. The first two smells
immediately visible are Long Method and Long Parameter List (see the
Code Smells sidebar for the names and descriptions of various code
smells). The original C++ method has twenty-eight lines of text, not
including blank lines. That's not terribly long, but this example
does exhibit some of the same design problems as other Long Methods.
We programmers tend to write Long Methods when we're thinking
procedurally-trying to get all those nagging details right, rather
than moving our thoughts up to a higher level and using abstraction and
composition to divide and conquer the problem. Sometimes a single
programmer writes the Long Method; other times it results from a
sequence of programmers adding one more thing (or one more bug fix) to
what was originally a not-so-Long Method. A Long Method is usually
guilty of several other code smells; eliminating them can often reduce
the Long Method to something reasonable.
To see more: http://www.stickyminds.com/BetterSoftware/magazine.asp
