|
 |
Home > Topics > Test & Evaluation > Detail: The Ghost of a Codebase Past
| |  |
The Ghost of a Codebase Past
By Pete Goodliffe
  
Summary: Revisiting your old code can be an enlightening experience. Pete Goodliffe encourages us to look back at our old code to see how our technique has improved, how our programming skills have progressed, and what we can learn from it. | | |
|
 |
Nostalgia isn't what it used to be—and neither is your old code. Who knows what functional gremlins and typographical demons lurk in your ancient handiwork? You thought it was perfect when you wrote it, but cast a critical eye over your old code and you'll inevitably bring to light all manner of code horrors.
Programmers, as a breed, strive to move onward. Few software developers stick with the same codebase for a prolonged period of time. The average programmer tends not to maintain his own code for too long. Rather than roll around in his own filth, he moves on to new pastures and rolls around in someone else's filth. Nice. Of course, it's fun to complain about other people's poor code, as we easily forget how bad our own work was.
Revisiting your old code can be an enlightening experience. It's like visiting an old relative you don't see very often. You don't know him as well as you think. You've forgotten things about him like his funny quirks and irritating ways. And you're surprised at how he's changed since you last saw him.
Looking back at your old code might make you shudder for a number of reasons.
Presentation
This is only an issue for languages that sanction ASCII-based artistic interpretation. Indeed, I rather admire languages like Java and C# with a de facto standard presentation style. It avoids many of the fractures over coding styles found predominantly in the C and C++ camps.
Some C++ programmers follow standard library layout like that in listing 1, and some have more Java-esque leanings like in listing 2. I know that my presentation style has changed wildly over the years, depending on the company I'm working for at the time. But as long as the style is employed consistently in your codebase, this is a trivial concern and is nothing to be embarrassed about.
The State of the Art
Most languages have rapidly developing built-in libraries. Thirteen years of evolution took Java's class library from a few hundred helpful classes to an unfathomable plethora of classes. C# is a relative newcomer to the development world, but over several major revisions its library has burgeoned and the language has grown myriad new facilities.
Such evolution—especially rapid in a language's early development—can render your code anachronistic. Anyone maintaining it might presume that you didn't understand language or library features, when actually they did not exist when your code was written.
C# gained generics in version 2.0. The 2004 code you'd have written, like that in listing 3, would today be written as listing 4. Indeed, listing 3 is potentially buggy and distasteful. The state of the art advances much faster than your old code.
Idioms
You can't help it as technology changes under your feet, but it's perhaps most embarrassing to look back at old code and see how unidiomatic it is. Once you learn the correct idioms for the language you're using, old code can look quite wrong.
Some time ago, I worked with a team of C programmers moving (actually, shuffling slowly) toward the brave new world of C++. One of the initial additions to their new codebase was called max and is shown in listing 5. (Do you know why we have all those parentheses? Post your answers in the comments section of my article on StickyMinds.com.)
Much later, someone revisited that early code and, knowing more about C++, realized how distasteful it actually was. This person rewrote it in the more idiomatic C++ shown in listing 6. This actually fixed some very subtle lurking bugs, which are illustrated in listing 6.
The original listing 5 version had yet another problem: The macro clobbered a name in the C++ standard library. This led to the even better solution shown in listing 7—Just use the built-in std::max function! It’s obvious in hindsight—the kind of thing you'd cringe about now but had no idea about back in the day.
Design Decisions
Did I really write that code in Perl? Did I really use such an inefficient sorting algorithm? Did I really write that by hand, rather than using a built-in library function? Did I really craft that awful interface for the module?
This class of problem is typically very hard to repair without a major code rewrite. This highlights why it's so important to make good design decisions up front and to ensure that your code has good modularity and is easy to change.
Bugs
Perhaps this is what dragged you back to an old codebase. We've all been there: A new bug has been discovered that forces you to look at some archaic code. Coming back with fresh eyes uncovers obvious problems that you missed at the time. How could this old stuff ever have worked?
Looking back over your old code is like a time-lapse code review, but it's a valuable exercise. Perhaps you should take a quick tour through some of your old work. Do you like the way you used to program?
It's important to understand how times have changed, how the programming world has moved on, and how your own personal skills have improved over time. Perhaps you don't have the time or opportunity to revise old code now, but knowing where you've come from helps to shape where you're going in your coding career.
Like the Ghost of Christmas Past, there are interesting cautionary lessons to be learned from our old code—if you take the time to look at it. {end}
How does your old code shape up in the modern world? If it doesn't look too bad, does that mean that you haven't learned anything new recently?
Join the conversation below or start a new one in the Member Comments section.
About the Author
Pete Goodliffe is a software developer, columnist, speaker, and author who never stays in the same place in the software food chain. His projects range from OS implementation, through audio codecs, to multimedia applications. Pete's popular book Code Craft: The Practice of Writing Excellent Code is a practical and entertaining investigation of the entire programming pursuit—in about 684 pages. No mean feat! He has a passion for curry and doesn't wear shoes.
Back to Top
 |
|
|
|
|
|
|
|
|
Testing Training Courses
Software Testing Certification, Systematic Software Testing, Test Management, Mastering Test Design, Just-in-time Testing
Software Engineering Training
Mastering the Requirements Process, Requirements Modeling, Introduction to the Capability Maturity Model Integration, Business-Driven Software Measurement
Agile Software Development Training
Scrum Master Implementation Workshop, User Stories and Estimation in Agile Development, Design Patterns Explained, Practical Test-Driven Development
|
|
|
|
|
|
|
|
