Beautiful Code [73]
Programs share some attributes with essays. For essays, the most important question readers ask is, "What is it about?" For programs, the main question is, "What does it do?" In fact, the purpose should be sufficiently clear that neither question ever needs to be uttered. Still, for both essays and computer code, it's always important to look at how each one is written. Even if the idea itself is good, it will be difficult to transmit to the desired audience if it is difficult to understand. The style in which they are written is just as important as their purpose. Both essays and lines of code are meant—before all else—to be read and understood by human beings.[*]
[*] This chapter was translated from the Japanese by Nevin Thompson.
You may ask: "Are human beings actually supposed to be the ones reading computer programs?" The assumption is that people use programs to tell computers what to do, and computers then use compilers or interpreters to compile and understand the code. At the end of the process, the program is translated into machine language that is normally read only by the CPU. That is, of course, the way things work, but this explanation only describes one aspect of computer programs.
Most programs are not write-once. They are reworked and rewritten again and again in their lives. Bugs must be debugged. Changing requirements and the need for increased functionality mean the program itself may be modified on an ongoing basis. During this process, human beings must be able to read and understand the original code; it is therefore more important by far for humans to be able to understand the program than it is for the computer.
Computers can, of course, deal with complexity without complaint, but this is not the case for human beings. Unreadable code will reduce most people's productivity significantly. On the other hand, easily understandable code will increase it. And we see beauty in such code.
What makes a computer program readable? In other words, what is beautiful code? Although different people have different standards about what a beautiful program might be, judging the attributes of computer code is not simply a matter of aesthetics. Instead, computer programs are judged according to how well they execute their intended tasks. In other words, "beautiful code" is not an abstract virtue that exists independent of its programmers' efforts. Rather, beautiful code is really meant to help the programmer be happy and productive. This is the metric I use to evaluate the beauty of a program.
Brevity is one element that helps make code beautiful. As Paul Graham says, "Succinctness is power." In the vocabulary of programming, brevity is a virtue. Because there is a definite cost involved in scanning code with the human eye, programs should ideally contain no unnecessary information.
For example, when type declarations are unnecessary, or when the design does not require class declarations and main routine definitions, brevity mandates that it should be possible to simply avoid them. To illustrate this principle, Example 29-1 shows a Hello World program in Java and Ruby.
Example 29-1. "Hello World" in Java versus Ruby
Java Ruby
class Sample {}
public static void main(String[] argv) {
System.out.println("Hello World");
}
print "Hello World\n"
Both programs accomplish exactly the same task—simply displaying the words "Hello World"—but Java and Ruby approach it in radically different ways. In Ruby's version of the program, all that's necessary is to describe the essence of the task. Print "Hello World". No declaration. No data type. In Java, though, it is necessary to include a variety of descriptions that are not immediately related to our intent. Of course, there is merit in including all of the things that Java does. However, because it is impossible to omit anything, brevity is lost. (To digress a little, Ruby's "Hello World" is trilingual: it also works in Perl and Python.)
Brevity can also mean the elimination of redundancy. Redundancy is defined as the duplication of information.