Beautiful Code [81]
Code is not strictly text, of course, but for the purpose of human readability, the same principles apply. Bookish code—that is, code formatted in book-like columns and chunks—is easier to comprehend.
Bookishness is more than simply keeping lines short. It's the difference between code that looks like this:
if( bf->end == bf->Lines() && lf1->end == lf1->Lines( ) &&
lf2->end == lf2->Lines( ) ) return( DD_EOF );
and code that looks like this:
if( bf->end == bf->Lines( ) &&
lf1->end == lf1->Lines( ) &&
lf2->end == lf2->Lines( ) )
return( DD_EOF );
The second of these code snippets is taken from DiffMerge. When we read it, our brains sense the scope of the logic at hand, and our eyes don't have to scan very far from side to side to take it in. (The fact that there's a visual pattern created by the choice of line breaks is also important; we'll get to that in a moment.) Being more bookish, the second snippet is easier to comprehend than the first.
Writing Programs for "The Book" > The Nonroyal Road
33. Writing Programs for "The Book"
Brian Hayes
The mathematician paul erdös often spoke of the book, a legendary volume (not to be found on the shelves of any earthly library) in which are inscribed the best possible proofs of all mathematical theorems. Perhaps there is also a Book for programs and algorithms, listing the best solution to every computational problem. To earn a place in those pages, a program must be more than just correct; it must also be lucid, elegant, concise, even witty.
We all strive to create such gems of algorithmic artistry. And we all struggle, now and then, with a stubborn bit of code that just won't shine, no matter how hard we polish it. Even if the program produces correct results, there's something strained and awkward about it. The logic is a tangle of special cases and exceptions to exceptions; the whole structure seems brittle and fragile. Then, unexpectedly, inspiration strikes, or else a friend from down the hall shows you a new trick, and suddenly you've got one for The Book.
In this chapter I tell the story of one such struggle. It's a story with a happy ending, although I'll leave it to readers to decide whether the final program deserves a place in The Book. I wouldn't be brash enough even to suggest the possibility except that this is one of those cases where the crucial insight came not from me but from a friend down the hall—or, rather, from a friend across the continent.
33.1. The Nonroyal Road
The program I'll be talking about comes from the field of computational geometry, which seems to be peculiarly rich in problems that look simple on first acquaintance but turn out to be real stinkers when you get into the details. What do I mean by computational geometry? It's not the same as computer graphics, although there are close connections. Algorithms in computational geometry live not in the world of pixels but in that idealized ruler-and-compass realm where points are dimensionless, lines have zero thickness, and circles are perfectly round. Getting exact results is often essential in these algorithms, because even the slightest inaccuracy can utterly transform the outcome of a computation. Changing a digit far to the right of the decimal point might turn the world inside out.
Euclid supposedly told a princely student, "There is no royal road to geometry." Among the nonroyal roads, the computational pathway is notably muddy, rutty, and potholed. The difficulties met along the way sometimes have to do with computational efficiency: keeping a program's running time and memory consumption within reasonable bounds. But efficiency is not the main issue with the geometric algorithms that concern me here; instead, the challenges are conceptual and aesthetic. Can we get it right? Can we make it beautiful?
The program presented below in several versions is meant to answer a very elementary question: given three points in the plane, do all of the points lie along the same line? This is such a simple-sounding problem, it ought to have a simple solution