8.1: Programming Plans

The first issue in this chapter is how to structure program logic. It reminds me of a story where a chess master once played a novice player, and after a few moves, the expert simply did not want to continue the game. The novice was making moves that bothered the expert because the moves made by the novice were so far removed from how the expert reasoned about the game.

A similar feeling emerges when an expert programmer looks at a novice’s (or even a poor professional’s) program. The programs just feel wrong. It is not just that indenting is off, and the novice programmer has followed some weird, or nonexistent naming standard, it is that nothing is organized correctly.

Most beginning programmers are taught that programs are algorithms where it is the logic that needs to be followed. At some basic level it is true that programs are logic that needs to be understood. However, research has shown that while beginning programmers (and poorly performing professionals) understand programming in terms of algorithmic flow, advanced programmers generally have created cognitive schema for a large number of problems, called programming plans. When reading and writing code these programmers will often look first to the plans, perhaps putting in a few lines out code to outline the plan, and only later going back to fill in the details.

To illustrate the difference between a code fragment using a logic-based approach and programming plans, consider a simple fragment to calculate the sum of values from 1 to n. When using logic, the novice is taught that they should initialize a sum to zero, and then create a loop. A loop will start at the for statement which initializes a variable j to 0, then moves to the next statement that adds j to the value of sum, and then at the end of the loop adds 1 to the value of j and goes back to the beginning of the loop, as in the following fragment:

int sum = 0; 
for (int j = 0; j < n; j++) { 
    sum = sum + j 
}

In the author’s experience this way of teaching looping is less than satisfactory. Even for the students who eventually get it, it is abstract and hard to follow, and some people never understand it.

A program plan, on the other hand, does not begin with logic, but with what is to be done, and the structure that applies to it. To calculate a sum, the programmer must start with 0 and add 1 to it for each number up to n. This we have:

sum = 0 + 1 + 2 + 3 + 4 + … n

To do this, we introduce a loop. All loops (counting or sentinel, or any other kind) have the following structure:

// initialize 
// start iteration 
// check if done 
// do iteration logic 
// get the next item 
// go back and do the next iteration 
// place to go when you are done 
sum = 0        // initialize 
j = 0 
while (j <= n) //check if done 
{ 
    sum = sum + j // iteration logic 
    j = j + 1 // get the next item 
    // Go back to the beginning 
} // Loop ends here

This is then called a summation loop, and the programmer refers to it when they need to write larger programs, such as an average program. An average program is simply a summation plan that maintains the number of items processed, and a final statement to calculate the average after the loop. This process of building larger programming is called plan merging.

While there is no research that I know of to say that students learn better when presented logic based programming or programming plans and plan merging, the research is clear that good programmers use programming plans.

But what is obvious to the author is that when doing assembly language programming, if users do not use block structures and procedural language programming constructs, but are left to their own devices, the results are almost uniformly bad. Some structure must be enforced, so block structured programming will be used with programming plans.