In addition, many programming languages include built-in error-checking features to keep you from writing a program that doesn’t work. With some languages, it’s possible to write commands that work perfectly but can also crash the computer if you give those commands the wrong type of data.
More than half the battle of programming is writing a program that works. The second half is modifying that program later. When you need to modify an existing program, you must first understand how that existing program works and then you need to modify it without messing up the existing program commands.
To help you understand how a program works, many programming languages let you divide a large program into separate parts. The theory is that if one part of a program isn’t working or needs to be modified, you can yank out part of the program, rewrite it, and then plug it back into the existing program, much like snapping LEGO building blocks together.
Finally, the best tools and the latest programming languages won’t help you unless you know how to use them correctly. That’s why computer scientists are constantly developing new programming techniques that work no matter what tools or language you use.
This chapter discusses programming techniques based on problems encountered by programmers working in the real world. Basically, computer scientists keep developing and refining programming techniques after they see what really works and what doesn’t.
Spaghetti Programming
In the early days of programming, most programs were fairly short and simple. A typical program may just calculate a mathematical equation, which to a computer, is just a little more challenging than adding two numbers together.
To write such small, single-task programs, programmers would typically start typing commands in their favorite programming language with little planning, just to write a program quickly.
Unfortunately, many programs aren’t just written once and then used forever. If a program isn’t working exactly right, or if the program needs to do something new that the original programmer didn’t include, you must take an existing program and modify it.
Modifying an existing program sounds simple, but it’s not. First, you have to understand how the program works so you’ll know exactly how to modify that program. If you try modifying a program without understanding how it works, there’s a good chance you could wreck the program and keep it from working, much like ripping out cables from your car engine without knowing what you’re really doing.
After you understand how a program works, the second step involves writing new commands into the existing program. Now, here’s where the problem occurs. Take an existing program and modify it once. Now take that same program and modify it again. Now take that same program and modify it 20 more times, and what do you get? Most likely, you’ll have a mishmash collection of code that works but isn’t organized logically, as shown in Figure 2-1.
FIGURE 2-1: Constantly modifying a program eventually creates an unorganized mess.
Modifying a program several times by yourself may not be so bad because you probably remember what you changed and why. But what happens if seven other programmers modify the same program seven different times and then none of them is around to help you understand what changes they made? Yep, you’d wind up with a bigger mess than before.
With constant modifications, a small, simple program can grow into a convoluted monstrosity that may work, but nobody quite understands how or why. Because the program consists of so many changes scattered throughout the code, trying to figure out how the program even works can get harder with each new modification.
With a simple program, the computer follows each command from start to finish, so it’s easy to see how the program works. After a program gets modified multiple times, trying to follow the order of commands the computer follows can be like untangling spaghetti (hence, the term spaghetti programming).
As programs kept getting bigger and more complicated, computer scientists realized that just letting programmers rush out to write or modify a program wasn’t going to work anymore. That’s when computer scientists created the first programming techniques to help programmers write programs that would be easy to understand and modify later.
SPAGHETTI PROGRAMMING WITH THE GOTO COMMAND
Although you can write spaghetti programs in any language, the BASIC programming language is most closely associated with spaghetti programming. Early versions of BASIC used a GOTO command, which essentially told the computer to “go to” another part of the program.
The problem with the GOTO command was that it could tell the computer to “go to” any part of the program. If you had a large program that consisted of several hundred (or several thousand) lines of code, the GOTO command could tell the computer to jump from one part of the program to another in any order, as the following BASIC program shows:
10 GOTO 5020 PRINT "This line prints second"30 END40 GOTO 2050 PRINT "This line prints first"60 GOTO 40
Line 10 (the first line) tells the computer to “go to” line 50.
Line 50 tells the computer to print This line prints first onscreen. After the computer follows this command, it automatically runs the next command below it, which is line 60.
Line 60 tells the computer to “go to” line 40.
Line 40 tells the computer to “go to” line 20.
Line 20 tells the computer to print This line prints second onscreen. After the computer follows this command, it automatically follows the command on the next line, which is line 30.
Line 30 tells the computer this is the end of the program.
Even though this program consists of six lines, you can already see how the GOTO command makes the computer jump around, so it's hard to understand how this program works. Now imagine this program multiplied by over several hundred lines of code, and you can see how spaghetti programming can make reading, understanding, and modifying even the simplest program much harder.
Structured Programming
The problem with creating programs without any planning is that it inevitably leads to a mess. So, the first step involves keeping a program organized right from the start.
The three parts of structured programming
To keep programs organized, structured programming teaches programmers that any program can be divided into three distinct parts:
Sequences:Sequences are simply groups of commands that the computer follows, one after another. Most simple programs consist of a list of commands that the