Regularity

==Iteration – code and structures==

==="Go To Statement Considered Harmful"===

In the case of 10 Print the GOTO statement avoids most of Dijkstra's complaints. Putting a GOTO statement at the end of a one-line program that simply references itself does not leave much room for unexpected entrances and exits. However, expanding the program to take more than one line demonstrates the potential problems that GOTO introduces:

<pre>5 CHARCODE%=205.5+RND(1)

10 PRINT CHR$(CHARCODE%);

20 GOTO 5</pre>

This code is functionally identical to the one-line version of 10 Print, but is a bit more representative of how developers create more complex programs. Line 5 creates a variable called CHARCODE% that stores a character code determined by the same formula used in the original 10 Print, but the character code is not used until line 10 when it is printed to the screen. Line 20 has the GOTO statement that makes the program iterate, but it now points to the new beginning of the program at line 5.

Already there is one potential problem: what if the programmer had forgotten to change GOTO's target from line 10 to line 5? The program would still function, but since the loop only returns to line 10 CHARCODE% never changes and the program only prints the same character over and over again with no randomization. Nowhere in this code does it say that the computer must select a random character code every time it prints a character, it is only implied by the fact that line 10 comes after line 5. GOTO allows the programmer to reference any line of code, however; it is just as valid to say GOTO 10 as it is GOTO 5, regardless of the intention that line 10 always executes right after line 5. GOTO's ability to target arbitrary line numbers means that sections of code that are intended to be monolithic can be entered at any point instead of just the beginning of the block.

GOTO's potential problems only get worse when it is combined with other flow control statements. Consider this variant of 10 Print:

<pre>1 FOR I = 0 TO 999

5 CHARCODE%=205.5+RND(1)

10 POKE 1024+I,CHARCODE%

15 NEXT I

20 GOTO 1</pre>

This version uses a FOR loop to fill the entire screen with the two 10 Print characters, beginning at the top-left corner. Immediately after finishing the FOR loop the program hits line 20 and GOTO sends execution back to line 1, restarting the loop from the beginning. If the forgetful programmer again fails to update line 20 though, leaving it as:

<pre>20 GOTO 5</pre>

The program will now not only fail to work as intended, it will fail to work at all and throw an error:

<pre>? NEXT WITHOUT FOR ERROR IN 15</pre>

Unlike the previous version where lines 5 and 10 were only implied to be a block, lines 1-15 are now explicitly a block of code defined as a FOR loop. NEXT relies on FOR, but since the block was re-entered on line 5 FOR never executes and NEXT is no longer valid. Using GOTO has short-circuited the other flow control structures that are critical to the language.

(tk may be clearer with diagram?)

=== Structured programming ===

Dijkstra's comments about GOTO were part of a movement toward programming languages that are designed for structured programming. Dijkstra himself would later take the idea further in his Notes on Structured Programming. Instead of viewing a program as line after line of text, structured programming practices involve seeing a program as an abstract set of tasks to be completed. Each of these tasks can be completed independent of one another; one section of the program can be written without worrying about how it is going to reference other sections because they share a common method of moving data between them. At a high level, programmers do not need to worry about how each function will work, they just know that it will and this knowledge allows them to plan their code strategically. Dijkstra compared this model to a string of pearls:

<blockquote>One of the metaphors in which I find myself thinking about the program structure envisaged regards the programs as a necklace, strung from individual pearls. We have described the program in terms of levels and each level contained "refinements" of entities that were assumed available in higher levels. […] I use the term "pearl" for [individual functions].</blockquote>

==== OOP ====

==== Recursion ====

=== Design and feedback ===

==== Iterative design ====

==== Testing as development ====

==== Agility and reuse ====