Clues to Understanding the Meaning in Programs

The meaning of business application programs is bound up with the meaning and description of data elements. In a typical business application program, there are as many references to data elements as there are lines in the program (the number of lines with more than one reference is about equal to the number with no reference). A great deal of the history of best practice in programming revolves around methods to make code more understandable to humans. This section reviews some of these practices from the standpoint of how they reveal the semantics that have been embedded.

Module Size

For 30 years managers, designers, methodologists, and other programmers have been exhorting programmers to keep modules (subroutines, methods, etc.) to a human scale (a page of printed text). The computer doesn't care. The semantics don't care. It's only the maintenance programmer who has to deal with this, and studies have shown that as the size of a module increases, the odds of it being correctly interpreted drop drastically.

With the help of some of the following techniques, a competent programmer can look at a page of code and can generally understand what is going on.

Data Hiding

One of the key conventions is "data hiding," or making sure that there isn't some other access to the data this module is dealing with that would create unwanted side effects to this particular module's processing. In the early days of mainframe programming, it was common to define all your variables in one common "global" area, and then let any of the subroutines access that data.

The problem with this approach is that you cannot evaluate what a module is doing if one of its subroutines is manipulating its data without providing any clue that this is occurring.

Cyclomatic Complexity

The prohibition against using "goto" commands in most programming languages is not so much that there is anything "wrong" with the "goto" command (if it were really that bad, it would have been excised from programming languages a long time ago), but what was found in practice was that the use of "goto" coincided with programs that had a high degree of cyclomatic complexity.^[21]

Cyclomatic complexity is a measure of the number of possible paths a given execution can take through a module. In general, adding conditionals (if statements, case statements, etc.) to a program increases its cyclomatic complexity. The greatest increases in cyclomatic complexity are caused by nested looping structures in which the execution can conditionally exit different places in different ways.

The computer doesn't care about cyclomatic complexity; it handles it just fine. Indeed, some legacy systems continue to this day because they do what they were supposed to do, and maintenance programmers are afraid to touch them because they are so complex that programmers are unsure of the impact of any change they might make on the implemented (and tested over time) semantics.

Naming Conventions

The final convention that leads to semantic understanding is use of naming conventions. Anyone who has tried to maintain a program with poor naming conventions understands this experientially, but perhaps they haven't reflected on why this is so.

Case Study: Labowe's Program

Labowe was a programmer on one of my first projects. One day, to overcome the drudgery of cranking out yet another inventory-related program, he wrote the whole program, tested it, and then used the editor to replace all the local variable and internal subroutine names with women's names. (This code was written in DIBOL, a high-level language that Digital Computers used at the time.)

The result was a program that was hilarious to read, with lines like

   If (NOT Sally) then goto Susie   Else call Sarah(Sandy). 

And so on. What was almost as comical as the anthropomorphized text was the fact that it processed inventory receipts exactly as the spec required. While we were testing it in the interpreter, and howling at statements like

   Processing interrupted at Jamie 150; "Jessica" undefined, 

we were busted by our bosses, who insisted that this was "unprofessional" and required that we clean it up.

Not being one to take defeat easily, Labowe resorted to the naming conventions that we had recently been taught in an assembler language course, which were based on some very old (and counterproductive) standards that hadn't been removed from the course. The conventions were to (1) index every line of code with the page and line number based on when it was first written (and sent off-site to be keypunched!) and then (2) to name variables based on the line and page number where they were defined.

So, Labowe's "professional" version of the program became

   If (NOT AA110) then goto BB104   Else call BA224(AC107). 

No more understandable, and certainly less fun.

I bring up the story in the sidebar to point out the crucial role of semantics in human understanding of programs, and how we use language for our clues to semantics. Had the programs been given semantically meaningful names—for example, If (NOT OutOfStock) then goto PickListCreation—a maintenance programmer would have had a much better chance of understanding this. But it doesn't make any difference to the computer.

Not all semantics are created equal. There are principles that lead to better (i.e., more precise, easier to understand) semantics, and we will discuss them in more depth later in this book.

^[21]Edsger W. Dijkstra, "Go to statement considered harmful," Association for Computing Machinery Magazine, March 1968, pp 147–148 (letter).