Beautiful Code [211]
The beautiful design here is that the tests not only tell you under which conditions you can use the routines, but also give you a validation example that allows you to build confidence and know what's going on—without really looking into the code.
The Long-Term Benefits of Beautiful Design > Inner Beauty
15.4. Inner Beauty
Now, let's start looking at the code's implementation details.
15.4.1. Beauty in Brevity and Simplicity
I believe that beautiful code is short code, and I find that lengthy, complicated code is generally quite ugly. The SGBSV routine is a prime example of the beauty of short code. It begins with a quick verification of the consistency of the input arguments, then continues with two calls that logically follow the mathematical algorithm.
From the first glance, it is obvious what this code is doing: it begins by performing LU factorization with the SGBTRF routine, then solves the system with the SGBTRS routine. This code is very easy to read. There's no need to pore over hundreds of lines of code to understand what the code does. The main task is split into two subtasks, and the subtasks are pushed into a subsystem.
Note that the subsystem adheres to the same design assumptions regarding memory usage as the main system. This is a very important and beautiful aspect of the design.
The routines from the subsystem are reused in different "driver" routines (the SGBSV routine is called a driver routine). This creates a hierarchical system that encourages code reuse. This is beautiful, too. Code reuse significantly reduces the effort required for code development, testing, and maintenance. In fact, it is one of the best ways to increase developers' productivity and reduce their stress. The problem is that reuse is typically difficult. Very often, code is so complicated and difficult to read that developers find it easier to rewrite code from scratch than to reuse somebody else's code. Good design and clear, concise code are vital to promoting code reuse.
Unfortunately, much of the code written today falls short in this respect. Nowadays, most of the code written has an inheritance structure, which is encouraged in the hope that it will bring clarity to the code. However, I must admit that I've spent hours on end staring at a few lines of such code…and still could not decipher what it was supposed to do. This is not beautiful code; it is bad code with a convoluted design. If you cannot tell what the code does by glancing at the naming conventions and several code lines, then the code is too complicated.
Beautiful code should be easy to understand. I hate reading code that was written to show off the developer's knowledge of the language, and I shouldn't need to go through 25 files before I can really understand what a piece of it is really doing. The code does not necessarily need to be commented, but its purpose should be explicit, and there should be no ambiguity in each operation. The problem with the new code being written today—especially in the C++ language—is that developers use so much inheritance and overloading that it's almost impossible to tell what the code is really doing, why it's doing it, and whether it's correct. To figure this out, you need to understand all of the hierarchy of inheritance and overloading. If the operation is some kind of complicated overloaded operation, this code is not beautiful to me.
15.4.2. Beauty in Frugality
My next criterion for beautiful code is that you can tell that a lot of thought went into how the code will be running on the computer. What I'm trying to say is that beautiful code never forgets that it will be running on a computer, and