Structured Programming

It occurred to me today that perhaps I have been giving program structure short shrift and that this might be causing me some difficulty in locating a job.

I saw an ad for a job the other day where they wanted someone who was familiar with graph theory. Graph theory? What's that? So I go look it up on Wikipedia and it looks like nothing more than state machines: nodes (or vertices) connected by lines. I've used this stuff so much it's second nature to me. Discussing it would be like asking a carpenter about his hammer. It's just a tool, I use it to hit nails. What else would you use it for?

Then I got to thinking about some of the code I have seen that was written by other people. There was one programming project I worked on at school with a small group of people. I took a look at one of the other guys programs and I could not believe how twisted it was. True it was written in FORTRAN and FORTRAN uses lots of goto's, but geez. Jump forward, jump back, jump sideways. I gave up trying to follow it after about five minutes. There just didn't seem to be any pattern to it at all.

At my first programming job my boss asked me to take a look at some code written by one of the other guy's there. He wanted me to do something with it, add something or fix something, I don't recall. This one was written in BASIC and it had the advantage of at least being able to run. I was able to make some headway in deciphering, but it was still really twisted. I went to the guy who wrote it in an attempt to get some help in understanding what was going on. I intended to be tactful, but the first words out of my mouth were "this is twisted", and that pretty much put an end to any conversation or cooperation.

I imagine that those incidents stand out because I was just out of school where I had only been exposed to pristine, well designed programs, and encountering such horrible creations was a veritable shock to my system.

I still run into bad examples. Perhaps they don't bother me as much because I have gotten better at deciphering them. The last one I ran into came from a data logger that had been designed ten or fifteen years ago and had then been updated annually by a different person. Some with talent, and some without, and some with PhD's. Sometimes I think the PhD version is the worst. That kind of code takes a couple of pages to assign a value to a variable. You see, if you are an expert, you cannot do anything simple, you must build enormous imaginary structures and populate them with all manner of wonderful beasts. You cannot refer to anything directly, but only by the imaginary name that you have created to refer to the beast that guards this particular piece of information. In other words, it's mostly horse puckey.

When I write code, I try for simplicity and clarity. Some people make a big deal about design, but for me the design is usually done the first day of a project. It may be that the projects I am working on are so simple they don't require a lot of thought, or maybe it is because I am clear thinker and the requirements for the project just "naturally" shape the design of the program. Or maybe I'm just a frickin' genius.

After the design, it's just a matter of filling in the blanks. Of course some programming projects can have hundreds or even thousands of blanks, but if the design is a good one, then it will work. Now occasionally, something may crop up at a later date that will require revising the design, and sometimes it may render the complete top level code obsolete. But if the design is at all appropriate to the task at hand, all the lower level code should survive unscathed. Sometimes that is just wishful thinking.

The design I did for a data logger was primarily command centric. We had a serial communications port that was connected to a PC running a terminal emulator program like Hyper Terminal. The logger would transmit a prompt character and wait for the user to enter a command. When the command came, the logger would search through an array of data structures for one that contained the command that matched the one that the user entered. When it found the match, it would retrieve the address of the corresponding procedure from this same data structure and call it. The procedure would do whatever it was supposed to do and return. Nothing simpler.

Could have used a binary search to look up the command, but there were only about 100 different commands available, and we are talking about the user interface, so we had plenty of time. We could look up the command before the user had let up on the enter key, a matter of milliseconds at most. The big advantage to this design was that a new command could be added without disturbing the top level code that called it. Write the command procedure and put the command and the address of the corresponding procedure in the table and you are done.

A second part of the design for this program required adherence to some rules. A big part of this project was configuration. There were any number of parameters/variables that could be set at when the device was installed and should remain undisturbed thereafter. These configuration settings were used all over the program, in the most obscure places. How can you protect these variables from being modified after the initial setup has been completed? One way, the modern way, the safe way, is to provide a procedure for reading each of these values. A couple hundred values, you say? No problem, we just add a couple of hundred procedures. What a pain.

True, I could have written a macro to generate all the needed procedures from a list of the required variables, but it would still generate several more pages of code. Do we really need to do this? Well, if we can enforce the rule that the variable is not modified except where it is specifically allowed, then, no, we don't. And as I was chief jerk and bottle washer on the project, I could make whatever rules I wanted, and if anyone broke them, I would have only myself to blame. As all these configuration variables were stored in a structure, every reference to them used this structure name, so as long as the structure name was easy to recognize, the variable references were easy to recognize, and perhaps as importantly, easy to locate. The plan worked very well. I obeyed my own rules and so I didn't have to punish myself.

As far as looking for a job goes, I think some of these people are trying to protect themselves from hiring people who can't write comprehensible code. I've heard rumors that most programmers cannot actually write a program. They may know something about programming, and they might be able to cut and paste, but they cannot actually write a program on their own. On one hand I find this shocking. For me it's the easiest thing in the world. On the other hand, I have seen some truly horrible examples what people produce. So I am ambivalent about this whole thing.

I suspect this whole C++ thing with "structured programming" and "object oriented design" may be a reaction to this problem. On the other hand, there are some fairly bright people out there who can make good use of the new features found in C++. I would love to have an opportunity to try it out. My only problem is I don't have any programming problems, much less a difficult one that would require "advanced features".

Update December 2016 replaced missing picture.