14.2. Statements Whose Order Doesn t Matter

14.2. Statements Whose Order Doesn't Matter

You might encounter cases in which it seems as if the order of a few statements or a few blocks of code doesn't matter at all. One statement doesn't depend on, or logically follow, another statement. But ordering affects readability, performance, and maintainability, and in the absence of execution-order dependencies, you can use secondary criteria to determine the order of statements or blocks of code. The guiding principle is the Principle of Proximity: Keep related actions together.

Making Code Read from Top to Bottom

As a general principle, make the program read from top to bottom rather than jumping around. Experts agree that top-to-bottom order contributes most to readability. Simply making the control flow from top to bottom at run time isn't enough. If someone who is reading your code has to search the whole program to find needed information, you should reorganize the code. Here's an example:

C++ Example of Bad Code That Jumps Around

MarketingData marketingData; SalesData salesData; TravelData travelData; travelData.ComputeQuarterly(); salesData.ComputeQuarterly(); marketingData.ComputeQuarterly(); salesData.ComputeAnnual(); marketingData.ComputeAnnual(); travelData.ComputeAnnual(); salesData.Print(); travelData.Print(); marketingData.Print();

Suppose that you want to determine how marketingData is calculated. You have to start at the last line and track all references to marketingData back to the first line. marketingData is used in only a few other places, but you have to keep in mind how marketingData is used everywhere between the first and last references to it. In other words, you have to look at and think about every line of code in this fragment to figure out how marketingData is calculated. And of course this example is simpler than code you see in life-size systems. Here's the same code with better organization:

C++ Example of Good, Sequential Code That Reads from Top to Bottom

MarketingData marketingData; marketingData.ComputeQuarterly(); marketingData.ComputeAnnual(); marketingData.Print(); SalesData salesData; salesData.ComputeQuarterly(); salesData.ComputeAnnual(); salesData.Print(); TravelData travelData; travelData.ComputeQuarterly(); travelData.ComputeAnnual(); travelData.Print();

This code is better in several ways. References to each object are kept close together; they're "localized." The number of lines of code in which the objects are "live" is small. And perhaps most important, the code now looks as if it could be broken into separate routines for marketing, sales, and travel data. The first code fragment gave no hint that such a decomposition was possible.

Cross-Reference

A more technical definition of "live" variables is given in "Measuring the Live Time of a Variable" in Section 10.4.

Grouping Related Statements

Put related statements together. They can be related because they operate on the same data, perform similar tasks, or depend on each other's being performed in order.

Cross-Reference

If you follow the Pseudocode Programming Process, your code will automatically be grouped into related statements. For details on the process, see Chapter 9, "The Pseudocode Programming Process."

An easy way to test whether related statements are grouped well is to print out a listing of your routine and then draw boxes around the related statements. If the statements are ordered well, you'll get a picture like that shown in Figure 14-1, in which the boxes don't overlap.

Figure 14-1. If the code is well organized into groups, boxes drawn around related sections don't overlap. They might be nested

If statements aren't ordered well, you'll get a picture something like that shown in Figure 14-2, in which the boxes do overlap. If you find that your boxes overlap, reorganize your code so that related statements are grouped better.

Figure 14-2. If the code is organized poorly, boxes drawn around related sections overlap

Cross-Reference

For more on keeping operations on variables together, see Section 10.4, "Scope."

Once you've grouped related statements, you might find that they're strongly related and have no meaningful relationship to the statements that precede or follow them. In such a case, you might want to refactor the strongly related statements into their own routine.

cc2e.com/1465

Checklist: Organizing Straight-Line Code

• Does the code make dependencies among statements obvious?

• Do the names of routines make dependencies obvious?

• Do parameters to routines make dependencies obvious?

• Do comments describe any dependencies that would otherwise be unclear?

• Have housekeeping variables been used to check for sequential dependencies in critical sections of code?

• Does the code read from top to bottom?

• Are related statements grouped together?

• Have relatively independent groups of statements been moved into their own routines?