Structured Programming

There are several important directions in programming that have emerged over the years. One is the move to structured programming. First articulated in 1958 by Edsger Dijkstra, structured programming refers to the idea that programs should have a carefully thought-out (and documented) structure. This is really common sense, of course, but computer programming was developed over time by a lot of hard-pressed (harassed might be a better word) individuals who generally built on what went before. The most serious problem with contemporary programming techniques, in the view of Dijkstra and his colleagues, was the use of so-called "spaghetti code" in which the logical flow of a program meandered all over the place, leaving the code unreadable and therefore difficult, if not impossible, to debug and maintain.

Advocates of structured programming derided the use of the "goto" statement (code that tells the system to "go to" some other place in the program for the next command to execute—usually a subroutine). "Goto" statements, in their view, comprised the first step in taking the programmer off into some hard to decipher direction. As an alternative, they advocated "if-then-else" logic supplemented by recursion—having the program reuse an instruction with a slight variation. It's not really possible to illustrate the difference between these two approaches without taking a rather long detour into programming. Moreover, the argument about whether the "goto" should be used at all still rages. The point is that this debate helped focus programmers on the need to write code that had a clear logical flow.

Quick! Hide the Information! Information hiding is a programmer's term that has nothing to do with security. Rather, it refers to how data are organized, manipulated, and presented. From one perspective, information hiding is just another element of modularization. For example, if a part of a payroll program calculates bonuses based on sales, you don't want to put either the calculation or the sales data into the main program. You put both in a module, and the main program doesn't know or care how the data are organized or how the calculation is done. It simply asks the module whether a bonus is needed for a particular person when the payroll is run. In the early days of computing, the nature of the data usually dictated how the program was written. For example, if a program was focused on managing customers of an electric utility, the developer might have assumed the existence of a meter for every customer. This uniqueness made it very difficult to move standard blocks of code from one element of a program to another—you couldn't use your utility modules for insurance customers, even though most of the work of managing customers is the same in both cases. This specialization also exacerbated the challenge of interfacing different databases because most components of the program were linked to the kind of information in the database. By contrast, information hiding, which is central to OOT, creates a general design that can accommodate a wide variety of data. "Customer" would now be a class, with special iterations for utility, insurance, and so forth. Putting the data in the background accelerates programming and eases database linkages.

Structured programming also argued for careful organization of the source code, in particular for making the program as modular as possible. The use of modules has several advantages:

Of course, structured programming insists on extensive commenting, which is language inserted into the source code that explains what the program is supposed to be doing at that point.

Certainly, these recipes for good programming are not in any way revolutionary—no one is accorded a genius for thinking of them. In fact, the only reason they get so much attention is that they came at a time when software development was in crisis. As the capabilities of computers had expanded, so had the ambitions of managers to make the best possible use of their investment. Vast, complex software development projects had become the norm, especially after the appearance of IBM's System/360 computers enhanced the affordability of powerful machines. Suddenly, lots of users were observing the same phenomenon that IBM had encountered in developing the System/360's operating system—software projects don't scale well. In particular, as noted, adding more programmers increases communications problems and leads to serious bugs as the right hand not only doesn't know what the left hand is doing, but can't begin to keep track of the several hundred other hands. After the software crisis was recognized (there was actually an international conference by that name), the writing of software became a more professional activity and the term software engineering came into widespread use.

Project Modeling

A second major direction in the reform of programming has been focused not on the code itself but on the part of the total effort that precedes coding. This approach places an emphasis on modeling. Analysts study the program requirements and build a model (likely in a flow diagram) of the result before any code is written. The often used analogy is to building a house. You should no more start a program by writing code than you would begin to build a house by nailing some boards together. The classic approach to programming is the "waterfall method" (see Figure 8.3 for a simplified version).

Function at the (Silicon) Junction More loose language from the computer front. The terms function and procedure represent an action that a computer program can perform. For example, Windows has a function for opening a new window. An application program—let's say, a word processor—issues a function call to Windows, asking it to do this (the syntax for this and other function and procedure calls are a part of Windows' API). Similarly, when a programmer creates a subroutine in a program, it gets a name and becomes a function that can be called from elsewhere in the program (or by another program, depending on whether the programmer publishes an API). In the minds of some specialists, there is a technical difference between a procedure and a function; for the purposes of this book, though, they are the same thing.

Modular Programming

A third major trend in programming reform has been the idea of code reuse, an extension of structured programming's call for the use of modules. Program subroutines are often painstakingly written to solve a complex problem; for example, as noted previously in this chapter, a programmer might write a subroutine that would be called every time his program needed to execute an algorithm, such as calculating an automotive lease payment or setting up optimistic estimates for Orange County investments. If written carefully, subroutines like this can be used over again, not just in the same program but in a completely different program. Obviously, the more convoluted the algorithm, the more benefit, but programmers have long appreciated the value of building libraries of subroutines that can be reused. Unfortunately, in normal programming, reusing code is difficult because although subroutines appear to be off to the side, in traditional programming languages it is very difficult to make them really separate. One of the principal advantages of object-oriented programming, which we'll discuss a bit later in this chapter, is that its objects are conceived and built in a way that makes them easier to reuse than subroutines.