Writing Structured Code and Using Structure in Development

June 4, 1998
by the DOUG staff

It becomes more apparent every time that I work with non programmers how critically important it is to include structure in your code and in your development practices. In fact, one of my clients keeps telling me that the current project is a "learning process" when in fact, it is an unstructured journey where we plod along till we hit a wall and then find out how to walk around it. Why I didn't insist on a spec ten times more, I do not know but this is not the first time I've run into this. It is the structure that we set up that provides the framework which allows the project to succeed. Many producers and graphic designers really need to know this and often just don't get the stringent requirements that "we" need to successfully program a project.

As it applies to project management and product development, it applies to the code you are writing itself. Most Director programmers that I know of (including myself) started out with a few "go the frames" and then started defining global variables until there were enough to feed the world. Most of us start out by experimenting and trying to see "what this thing can do." Now that approach is not bad because it allows the new programmer to grow and be able to create small projects in an easy manner. The problems start when a programmer with this type of approach tries to tackle larger projects.

Larger projects are more complex by nature and part of this complexity is the management of all your variables and routines. When you save your tax receipts for Uncle Sam, do you lump them all in your shoebox or do you eventually seperate them into appropriate categories and then add them up? Well, it's the same concept that file cabinets were built on. Put relevant things in the same folder and you will always know where they are. Hence the importance of objects and behaviors. This structured approach is more information and data management than anything else.

Honestly, I look at my old code with 50 globals and say "gee, if I hadn't written this, I wouldn't know where to start." And sadly, it's true; but that's part of the learning process. At the end of every project, I like to look back and say, "having done this once, how would I do it better next time?" And what it always comes down to is structure and organization. There are a few concepts that will always need to cement themselves in my mind but how your code is structured determines many important things:

its maintainability
how easy it is to isolate a problem and...
how easy it is to get variable info on only the stuff that you want to be concerned about (no info overload)
how easy it is to upgrade and expand
how easy it is to document and therefore understand

A goal should be to lay out a functionality breakdown ala an overview. Many folks like to tunnel down to the exact functionality for a specific section but that does not help you here. Figure out what you want your program to do. Figure out the major sections of your program and list them. Then check out the functional subsections of these sections. If you have trouble doing this, then your program is not structured well enough and probably should be re-thought. After this, determine how your functional areas communicate with each other and define these interactions. Once this has been done, you can then flesh out each of the functional areas and redesign as necessary till the product starts to form. This is very valuable because it will set up a pattern for the future and also give you info on how long this process takes so that you can have better info on how to keep development costs under control and be better able to quote prices to clients.

Actually, the current project that I have been talking about is succeeding only because of the structure put into the project. Since the "producer" does not realize the absolute requirement of spec and careful planning, the fact that the program is organized allows me to make 1 change and affect how all buttons behave. So this structure can also allow you to survive when dealing in a project where you do not have all the control and the producer has little idea of the demands placed on the programmer.

Now all this does not scream out OBJECT ORIENTED EVERYTHING but it simply will help IF you decide to take that route. It does say that outlining and organizing the functionality and programming of your project will make your life easier. And that's not a bad thing now is it? :]