Better Software - March 2009 - (Page 18) Code Craft The Ghost of a Codebase Past by Pete Goodliffe 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 ASCIIbased 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. class standard_style { int variable_name; bool method_name(); }; Listing 1 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. class JavaStyle { int variableName; bool methodName(); }; Listing 2 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 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. 18 BETTER SOFTWARE MARCH 2009 www.StickyMinds.com ISTOCKPHOTO http://www.StickyMinds.com
For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.