in reply to Re: Re: Re3: A matter of style
in thread A matter of style
Excellent link. I think the following quote from it is extemely illuminating. (And rings a particular bell for me, the reformed pascal programmer :-)
The canonical example of the loop-and-a- half problem is precisely the one that Knuth describes: reading a set of input values until some sentinel value appears. If the basic strategy is expressed in pseudocode, the problem has the following solution:
loop read in a value; if value = Sentinel then exit; process the value endloop;
In this example, the loop/exit/endloop statement is an extension to the Pascal repertoire and represents a loop that is terminated only by the execution of the exit statement in the interior of the loop body. The loop/exit/endloop extension makes it possible to express the algorithm so that the input value is read in from the user, tested against the sentinel, and then processed as necessary.
The loop/exit/endloop approach, however, offends the sensibilities of many computer science instructors, who have learned through their experience with Pascal to "unwind" the loop so that the test appears at the top of the while loop, as follows:
read in a value; while value != Sentinel do begin process the value; read in a value end;
Unfortunately, this approach has two serious drawbacks. First, it requires two copies of the statements required to read the input value. Duplication of code presents a serious maintenance problem, because subsequent edits to one set of statements may not always be made to the other. The second drawback is that the order of operations in the loop is not the one that most people would expect. In any English explanation of the solution strategy, the first step is to read in a number, and the second is to process it by adding it to the total. The traditional Pascal approach reverses the order of the statements within the loop and turns a read/process strategy into a process/read strategy. As the rest of this section indicates, there is strong evidence to suggest that the read/process strategy is more intuitive, in the sense that it corresponds more closely to the cognitive structures programmers use to solve such problems.
Thanks very much for the link. That a keeper.
---
|
|---|