Structured Programming

[T. William Wells]

My two cents:

	Structured programming is the art of making the physical
	structure of the program mirror the logical structure of the
	problem to be solved.

This entails:

	1) Knowing the logical structure of the problem to be solved.
	2) Arranging the program to reflect that.

This helps to provide:

	1) A more correct program.
		The program is designed to do the right thing.
	2) A less buggy program.
		The program does what it is designed to do.
	3) A more easily understood program.
		Since form mirrors function, knowing either makes
		understanding the other easier. Also, there is the
		synergy of considering both why and how
		simultaneously.
	4) A more easily maintained program.
		A change in the function of the program translates
		directly into a change in the program since the
		program structure reflects its function.

These are common misconceptions:

	1) Structured programming requires a HLL.
		Oddly enough, it is easier to write structured
		programs in assembler than BASIC. Though you can do
		it in BASIC. Masochisticly.
	2) Structured programming means rigidly following one style.
		Structured programming means following the structure
		of your problem. Since problem types are unbounded
		(consider Goedel's theorem), so are the styles that
		will be appropriate to solving them.
	3) Structured programming makes better programmers.
		Cart before horse time: structured programming is a
		tool. Just as a better hammer makes properly driving a
		nail easier, so does structured programming make
		writing a good program easier; however, a hammer
		won't turn an all-thumbs into a carpenter, nor will
		structured programming turn a routineer into a
		competent programmer. The all time worst program I've
		seen was in 8085 assembler, but the number two spot
		goes to a properly structured (according to the
		mechanicalist school of structured programming)
		Modula II program.

---
Bill
{ uunet!proxftl | novavax } !twwells!bill