Beautiful Code [210]
Another example of this type of problem manifests itself in programs that use database systems. If such a program is written in the manner I just described, it could start constantly accessing the database when it is operating on the data. The programmer might think that the program's operations are trivial and fast, but they are actually very inefficient because they contain calls to the database.
So what is the lesson here? When writing beautiful code, one needs to think about its scalability. Contrary to popular belief, scalability does not come from code optimization; rather, it comes from using the right algorithm. Code profiling can provide hints about symptoms of poor performance, but the root cause of performance issues can generally be traced back to design issues. The SGBSV routine is designed so that it does not have this performance problem, and that is another thing that makes it beautiful.
Looking now at the other input arguments, it becomes clear that the same principle that applied to the AB array also applies to the others.
The final argument, INFO, is the error communication mechanism. It is interesting to see how the diagnostics are presented to the user. It is possible that the system of equations does not have a solution, and this case is also reported here. Notice that the INFO argument reports failure as well as success, and that it provides diagnostics to help you identify the problem.
This is something often lacking in code written today. Nowadays, code is commonly written to handle positive use cases: it is written to perform the actions detailed in the specification. With the sample code, this means that the code will work fine if the solution for the system of equations exists. However, reality is messy. In real life, code can break, and code dumps core or throw exceptions when it is presented with a system of equations that lacks a solution. This is a common case of failure to specify requirements about unexpected usages.
Many systems today are programmed to do as little as possible; then—once they are in use—they are "fixed" to do the things nobody initially anticipated they would need to do. A similar problem is the failure to specify requirements about how to gracefully handle errors and other unexpected situations. Such a response to exceptional circumstances is critical to application reliability and should be treated as a fundamental functionality requirement.
When writing code to a specification, developers need to recognize that specifications are usually incomplete. The developer must have a deep understanding of the problem at hand so that she can extend the specification with the additional use cases and unexpected usages that need to be implemented in order for the code to perform in an intelligent way. Our sample routine is one example of what happens when such careful consideration is applied. This routine will either do the job, or it will tell you that it cannot do it—it won't crash on you. This is beautiful.
Next, let's look at the routine's Further Details section. This section describes how the memory is used and makes it obvious that the space is used as the scratch space during internal operations. This is a good example of beautifully implemented code, so I'll be discussing this in the next section, "Inner Beauty."
Another example of the code's outer beauty is that many routines in the CERN library provide simple test and example programs. This