| Beautiful Code | ||||||||||
| Reviewed by Tal Cohen | Monday, 29 September 2008 | |||||||||
The quote above isn’t from Beautiful Code: it’s from The Story of Mel, a centerpiece of programmers’ folklore. And I find it to be very true, which is why a book titled Beautiful Code has an immediate appeal for me. Many chapters in Beautiful Code are a true joy, mostly because, well, much of the code is indeed beautiful. (Sadly, some chapters are not so joyful; more about that below.) To clarify, it is not just code that is being discussed: sometimes it’s about algorithms, design, API design, or architecture. But these are all fair game. The book consists of thirty three chapters, each by a different author, each presenting a different piece of code or design. Most chapters present code by the author (or authors), whereas some authors choose to discuss code written by others. Diversity is perhaps the strongest point of the book. First, there’s the diversity in topics, which range from the internals of the synchronization mechanisms of the Solaris operating system to the information portal used by NASA’s Mars Rover mission; from the design of source-code control systems to algorithms for counting the number of 1-bits in an array. The authors themselves are diverse, ranging from young hotshots to the wise elders of the programming community. There’s diversity of programming paradigms: procedural, object-oriented, and functional code are all present, and one chapter even employs aspect-oriented programming (using mechanics that predate AOP’s original presentation; AspectJ users will find it fascinating). For diversity in programming languages, the book deserves the International Polyglot Community Award. Code fragments are presented in C, C++, Fortran (66 and 90), Haskell, Java (SE and EE), JavaScript, Lisp (Common and Emacs Lisp), MATLAB, MSIL, Perl, Python, Ruby, Scheme, and, yes, Visual Basic. With the exception of the chapter using Scheme, authors using non-mainstream languages are kind enough to include brief explanations that make the code readable — in nearly all cases, the code’s beauty is not directly related to the author’s language of choice. I must admit, though, that there’s some irony in the usage of Perl when discussing beauty in code. I have encountered works by the Russian painter Nikolai Roerich, and in particular his paintings of the Himalaya, in two different contexts: in Beautiful Code, in a discussion of a web-based email client written in Perl; and in the novella At the Mountains of Madness, by H.P. Lovecraft. One is a work of art, the other is a tale of horror, and I shall leave it to the reader to guess which is which. An interesting challenge, while reading a book such as this, is to see if you can improve on the solutions outlined by the authors. It’s not always easy: many of the authors are, after all, true masters. Still, the exercise is a healthy one. Chapter 12, for example, discusses the design of the Bio::Graphics package, a celebrated Perl library used by many bioinformation researchers. Bio::Graphics’s design is unquestionably elegant, but here’s a minor suggested improvement: the mechanism for “glyphs” inside “features” can be used to dynamically define property values using callbacks. This allows for considerable flexibility, as callbacks often do. Better yet, a callback function can return the string ’’*default*” to indicate that the caller should just use the default value, unchanged. I would have designed it slightly differently, passing the default as an argument to the callback function. This way, the function can ignore the default (like returning a regular value in the current design), or return it (tantamount to returning ’’*default*”), but it can also return a variation on the default, such as “the default + 10%”, or “half the default value”, etc. But beautiful code that can have a minor polish is still beautiful. The book’s real problem is that some of the chapters present code which is, well, not beautiful. Some of it is awkward at times, some worse. Take the chapter discussing NASA’s information portal for the Mars Rover mission. Despite the promising subject, it discusses a simple web-based application written in Enterprise Java, and the code is mediocre at best. As part of a (generally boring) 200-odd lines fragment, we find the following code (p.331): if (reader != null) {By the time you reach the “else”, you have forgotten what the “if” was all about. Why not: if (reader == null) {Chapter 32, “Code in Motion”, explains exactly why losing the indent for those 20 lines of code is beneficial. Sure, it’s a minor difference, but I truly believe that the overall elegance of a solution can be greatly damaged if the author does not pay sufficient attention to the small details.Chapter 30, “When a Button is All That Connects You to the World”, shows how the problem can be more beautiful than the solution: how do you design an interface for a user (Professor Stephen Hawking) that can only press a single button — and must use it to communicate with the world? The author chose to highlight the beauty of the resulting UI; the code itself, he admits, is spaghetti. Further, I find it incredulous that the author never mentions (and clearly, the software doesn’t make use of) Markov chains. Adding insult to injury, the chapter ends with a discussion of a port of the program to Emacs, which has a well-known Markov-like feature, Dissociated Press. In some cases, faults in the code are more than just stylistic. In a chapter about integrating business services using REST, the author uses two iterators to read, in parallel, the keys and values stored in a hashmap (p.459). Because nothing in the API ensures that keys and values will be iterated in the same order, the code is downright buggy. It is this great unevenness of quality that is the book’s major bane. I believe the editors would have done wisely to reject a few of the submissions, yielding a smaller but higher-quality tome. My advice to the reader is this: do not feel obliged to read the book cover-to-cover. The first chapter, by Brian Kernighan, presents a true pearl (by Rob Pike), and sets a very high standard; not all other chapters are nearly as shining. If you encounter a chapter which bores you, or presents ugly code, just move ahead to the next one. Finding, say, 20 gems in a bag holding 33 stones is still a fantastic experience.
| ||||||||||
 |
 |
Indeed beautifull [by student] [Unfold this reply] |
©1997-2022 by Tal Cohen, all rights reserved. [About]
I have often felt that programming is an art form,