- 2.1. Our emphasis
- 2.2. The basic goal—a major difference between C++ and Java
- 2.3. Constructors and destructor
- 2.4. Operator overloading in C++
- 2.5. Operator overloading in Java
- 2.6. Flow-control constructs
- 2.7. Manipulating character strings in C++
- 2.8. Canonical class structure
- 2.9. Overcoming macrophobia
- 2.10. Program readability
- 2.11. Error detection and exceptions
This chapter is from the book
This chapter is from the book
This chapter is from the book
2.10. Program readability
2.10.1. Commentary and data names
A program is not only something to be run on a computer, it’s also a document for people to read. We assume that the reader is an experienced programmer, often the original programmer at a later time.
Good programmers use commentary in four places:
- Title comments introduce a class definition, an important function, a package of macro definitions, some other nontrivial module, or an entire source-code file. For proprietary programs, the title comment often includes a copyright notice.
- Introductory comments describe the purpose and usage of a class, function, or other module.
- Block comments describe the purpose and strategy of a group of related statements.
- Line-by-line comments explain an individual statement or even a part of a statement.
Program documentation is an integral part of programming, not a separate activity. Title and introductory comments are best written before the code. That helps you to clarify your thoughts and usually saves time. Line-by-line and block comments can be written before, during, or after the code. In complicated logic, block comments are often useful to explain the state of data items at that point.
Line-by-line comments should avoid stating what’s obvious from the code. Describe what is being done, not how. For example,
Not: ++posn; // Advance the position But: ++posn; // Skip over the comma Not: weight*=2.2; // Multiply by conversion factor But: weight*=2.2; // Convert to pounds Not: while(count>0) // Loop until count exhausted But: while(count>0) // Examine all work orders
By choosing meaningful data names, we often avoid the need for any line-by-line comment:
Not: while (count>0) // Examine all work orders But: while (workOrderCtr>0) Not: weight*=2.2; // Convert to pounds But: weightInPounds = weight * kgToPound;
Data names should be mnemonic, suggesting the purpose or usage of the data item from the point of view of the module. Names should be long enough to be mnemonic (or self-documenting) but not so long as to force typical statements to span multiple 80-character lines. Single-character variable names, such as k, are sometimes appropriate for abstract mathematical quantities or bound variables having a short scope (such as a loop index).
2.10.2. Format criteria and editor support
Criteria for writing easy-to-read code haven’t changed since the structured revolution of the 1970’s. Today, however, it has become harder to satisfy those criteria, because many of the editors and development platforms that we use to create and maintain C++ and Java source code fail to support basic page-layout facilities.
One excuse we hear is that programmers, especially younger ones, view their code only on a computer screen, where the text is continuous. Instead of turning a page, the programmer scrolls the text, using either a vertical scroll bar or the up and down keyboard arrows. If we never print the source code on hard copy, then why, some ask, should we care about page layout?
Actually, experience shows that it’s often much easier to comprehend a module on a 55-line page (or a pair of facing pages) than on a screen. No matter how comfortable you are with your online program editor, I strongly recommend that you print and save a paper copy every now and then, study it carefully, and make notes on it in red pencil.
2.10.3. Uncontrolled page breaks
One particularly irritating omission is the lack of any way to insert a hard page break. When the top line of a module appears at the bottom of a page, or when a four-line loop is split between pages, readability suffers.
Some programming organizations have developed their own source-code listing programs that interpret embedded commands, such as
//%EJECT
Others paste an entire module into a word processor and then edit the text to produce a readable presentation (or publication) copy. That’s too much labor, however, for everyday use, and it runs the risk of last-minute changes to the presentation copy that aren’t reflected in the compiled copy.
2.10.4. Page and line width
Even though we no longer prepare source code on 80-column punched cards, programmers still work with 80-position lines. Character display monitors and the “command windows” that mimic them are typically limited to 80-position lines. With 11-point monospaced font and normal margins, standard paper accommodates lines up to 80 characters.
Trouble arises because some of our source-code editors recognize no such limitation. They’ll let you keep typing 200 or more characters on a line. When you try to view such a line on the screen, you have to scroll the text horizontally, and when you print them on paper, they either get chopped off or continued (ruining your indentation) at the left margin of the next line.
Even without horizontal scrolling, the most popular screen resolution lets you enter 100 characters without realizing that you’ve gone off the page. You can still see the whole line on the page, but you can’t print it on normal paper.
If your editor doesn’t warn you when you’ve exceeded a standard line length, it probably displays the current character position in a corner somewhere. Keep an eye on it and don’t go beyond position 80. Since both Java and C++ syntax accept line breaks between tokens, you can always split a statement between lines in a highly readable manner.
2.10.5. A macro convention
The global.hpp definitions we introduced in Section 2.9.4 contain definitions for a set of macro names that enhance source-code readability:
#define INT const int #define DOUBLE const double . (and so on)
If you use these macro names, not only will you conserve horizontal space on the listing, you’ll also reduce the chance of forgetting const in the parameter list of a function. I strongly recommend extending this convention to classes you define. For example,
#ifndef COMPLEX
#define COMPLEX const Complex
class Complex{
.
.
};
#endif
2.10.6. Indentation and white space
Compare these two source listings:
)
The compiler considers them identical, but a human reader does not. You probably recognize the one on the left as the familiar binary search algorithm.
Although indenting lines to show the scope of flow-control constructs contributes greatly to source-code clarity, it’s silly to worry about the exact number of spaces to indent, whether to put brackets alone on separate lines, or similar minutiae. The programmer should be concerned with clear and attractive presentation of source code, not with complying with arbitrary and restrictive rules.
Blank lines also help to set off blocks of related code. Since they consume space when you view a program on a small screen and reduce the amount of actual code you can see, they provide another argument in favor of printing program listings on paper.
2.10.7. Alignment
A block of consecutive similar lines or of similar groups of lines is easier to read if corresponding elements are aligned. Note that in the binary-search indentation example, we also took care to align similar clauses.
Finally, compare these two:
)
The version on the right would be even less clear if rendered in a variable pitch font.