Beauty In The Eye of the Coder
In a YouTube interview with Lex Fridman -- Bjarne Stroustrup: Recognizing Beautiful Code -- Stroustrup is less paradoxical, but equally thoughtful:
It's easier to recognize ugly than to recognize beauty in code. . . sometimes beauty comes from something that is innovative and unusual, and you have to sometimes think reasonably hard to appreciate that. On the other hand, the messes have things in common.
I've always endeavored to write neatly indented, correct code with intelligent defaults and consistent return values, but in terms of beauty, that is a low bar. Code that runs wickedly fast can be beautiful, but perhaps that is more of a measure of cleverness. A better indicator of beauty, however, might be how well the code stands up to time.
Requirements change, database fields are added, code is refactored by multiple authors. Time conspires to distort and contort programs, but the ones that endure are often considered beautiful. For example, Unix pipes, redirection, and standard IO are beautiful and brilliant. Not code per se, these concepts have been present since the beginning of Unix (1971), and embody that which is clean, simple, and extensible.
Searching for these qualities in code, look no further than C and pointers to functions. I wrote about this in a C Programming Language post:
I've used them to create a more flexible print() routine which could format for various devices such as a screen, a printer, or a file. Instead of having high-maintenance if-else sequences, or a slightly better switch() statement, you had 3 separate functions -- one for each device -- and passed in the desired function to the print() routine.
Initially, I encountered some resistance from teammates. Pointers to functions were not as obvious as if-else sequences, but after setting them up and using them, colleagues remarked how easy they were to use, and how clear they were for maintenance. Also, printing to a new device -- say, a network socket -- just meant writing a 4th function and passing it into the print() routine. Bonus: the existing production code for writing to a screen, printer, and file, would remain safely untouched.
C's pointers to functions can be considered a precursor to object-oriented polymorphism. Indeed, C++'s overloading and overriding of methods are formal language mechanisms for something very similar.
This was back in the 1980s, when pointers to functions were new and strange, but today, it's a common technique.
Beauty can also be found in recursion, and I may have been too hasty when I relegated it to the academic world in a post about reversing a linked list. Recursion is also useful for compiler writers, where parsing tokens -- specifically their order -- can be unpredictable. And I've used recursion once to make socket connections. It's not as gratuitous as it sounds because the number of connections could vary; it could be primary and backup sockets on a local server, a remote server, or on future migrations and upgrades to new servers, but where the transition needs to happen gradually.
All these words about beautiful code are not meant to pressure developers to write such code all the time. Neatly formatted code with consistent naming conventions is a good thing, and makes up the bulk of my own code. Admittedly, a small percentage of my code is ugly. We all have written quick and dirty code with the intention cleaning it up later, only to find a cleanup release never happens. And hopefully, some percentage -- no doubt the smallest fraction -- of my code is inspired and enduring, and can be considered beautiful.
Comments