|
When was the last time you looked at a program listing and said "Now that's some fine looking code"?
August 09, 2005
URL:http://www.drdobbs.com/beautiful-code/184407802
How many times have you heard something to the effect of "Now that's beautiful piece of work?" I heard it often when I was an undergraduate. In fact, I distinctly remember Dr. Homer Austin using a phrase like that to describe the Fibonacci sequence.
After graduation I became a computer programmer, not a mathematician. With that, the word "beautiful" dropped from my professional use, if not from my professional vocabulary entirely. Still, one thing that was made very clear to me in school was that beautiful solutions were good solutions. Applying that to software development begs the question--what is "beautiful code"?
Someone might suggest that commercially successful code is beautiful, but that doesn't really help much--a "killer app" might be a great app, but its code could be ugly. Many code programs contain comments along the lines of 'here be dragons', and the expression "Don't touch fooboggle, it's huge, it's ugly, but it works" is no rarity. These functions may work, but they aren't beautiful--all we have identified is the absence of software goodness. This makes me wonder: What elements of "beauty" is all that bad code missing? If that code were different, how would it be different to beautiful? What does beautiful code have that bad code does not? After some thought, I've come up with a few things that I have consistently seen in code that I would call beautiful:
sub get_eligibility_of_coupon(coupon_id)
returns boolean;
struct eligibility_type(ok boolean, msg string, good_coupon boolean);
sub get_eligibility_of_coupon(coupon_id, optional date assume sysdate)
returns eligibility_type;
Assume a coupon_id is an integer. What happens in option 1 when you pass in -1? Or, for that matter, any value that isn't a valid coupon? Or Null? We don't know. To test option 1, we need to know some coupons that are valid or not valid as of right now. We probably have to write a query.
For option 2, we can create a list of coupons that are valid as of a certain date, then pass in that date. We can test all kinds of interesting scenarios like "what happens on leap years?" We can provide a different response if the coupon_id was invalid than if the coupon_id was just expired. In short, option 2 is testable. Murphy's Law applied means that testable code is better code.
I am not suggesting that this is a complete list on how to make beautiful software; it is just a start, a jumping-off point. I think it makes a point: Instead of searching for some automated measure of our codes efficiency in (lines of code)/function points + (1/defect density) blah blah blah perhaps we should be striving for beauty in our work because we believe that beautiful things are better. Perhaps we should be building and weighing our own list of what makes beautiful code. In fact, you could submit that beautiful code should fail gracefully, or Design-By-Contract , or have a unity of design, or a dozen other things. Even without conclusion, the very discussion is healthy.
Why should we study software beauty? Well, think about the list above. Beautiful code tends to be smaller--so we can write more powerful software in less time. It tends to be testable, so we can improve it's quality and more confidently maintain it. Because it does one thing and is well-separated, beautiful code lends itself to re-use, which results in still more functionality delivered in still less time. In short, beautiful code is good code. If we write more beautiful code, we will be better programmers. When people try to compare personal improvement in art to improvement in software, that's about the best I can come up with.
The good news about code beauty is that it is a space that hasn't been explored much; there is plenty of room for us to make our mark on the body of knowledge.
Ronald Jeffries, Andy Lester, Dr. Paul Jorgensen, Scott Kiwilski, and Chuck Dreyer contributed to this article.
Matthew Heusser is Technical Project Manager at Priority Health, where he manages in-house, integration, and outsourced software projects. He can be contacted at [email protected].
"Space that hasn't been explored much" and "space that hasn't been explored at alll" are two very different things. On the cover of The Practice of Programming Kernighan and Pike list "Simplicity, Clarity, Generality" as virtues to strive for. Paul Graham has done some writing on "Taste for Makers." You could argue that Martin Fowler's Improving the Design of Existing Code (Addison-Wesley Professional, 1999) is really a book on improving the beauty of existing code, while Pete McBreen's Software Craftsmanship: The New Imperative (Addison-Wesley Professional, 2001) and Dave Thomas and Andy Hunt's The Pragmatic Programmer: From Journeyman to Master (Addison-Wesley Professional, 1999) are a call to action for the software community--to re-frame programming as craft. Finally, Steve McConnell's Code Complete (Microsoft Press, 2004) is a classic on what "good" code looks like.