Preface

I still remember the first computer program I wrote. I composed it while standing in front of a TRS-80 at a Radio Shack store in Missoula, Montana. Then a 12-year-old, I had just seen my first "real" computer a few weeks earlier in my classroom. Our teacher taught us everything that he knew about the computer over one or two days, and I was fascinated. Cautiously I approached the sleek gray terminal with its glowing phosphor screen. With excitement welling up inside of me, I set my mind on the task at hand, reached out for the keyboard, and programmed my first software application.

10 FOR I = 1 TO 1000
20    PRINT I, I + 1
30 NEXT I
40 END

It may seem infantile, especially when you consider what you can do with the same amount of code in some more modern languages. But for a seventh grader with his first chance to write a real program, it was grand. It opened a whole new world for me. I can still recall the feeling I had as I stood there, watching the columns of numbers racing down the screen. That same feeling comes back to me every time I write a working program.

Over the years I have learned to write programs longer than four lines. I took the standard academic and business path through PASCAL, 8086 assembly language, LISP, C, and C++, but today I spend most of my programming career with a variant of the language that my fingers first typed: Microsoft Visual Basic. And why not? Visual Basic allows me to write complex applications for Microsoft Windows in a fraction of the time that it would take me to write the same programs in C or C++, with or without class libraries such as MFC and OWL. Visual Basic makes the creation of Windows applications literally child's play. However, along with the ease of Windows programming has come the ease of writing bad programs.

In the early days of computers, the skill of programming was limited to a few geeks who spent their lives cooped up in a stadium-sized computer room with a brain the size of a four-function calculator (the computer's brain, not the geeks'). These progenitors of modern software engineers spent hours choosing just the right punch cards to calculate π to 10 decimal places. The most powerful computers of the time were expensive, slow, and short on memory. It was in the programmer's (and his employer's) best interest to write well-crafted, concise, and error-free code the first time. Style was not an issue; if it worked, it was good enough.

Today the computing horizon is quite different. Once there were a few ENIAC-shaped mud huts; now Pentium-class high-rises dot the landscape. The latest machines are orders of magnitude faster than anything imaged by Charles Babbage, and they are priced within the budget of most technology-crazed consumers. The modern business climate requires that the average person understand how to operate a computer. With the advent of (relatively) easy-to-use programming languages such as BASIC, some employers are asking their business experts to translate that business knowledge into working computer applications.

Consider the case of Joe, an accountant for a small manufacturing company. Joe has worked for years literally "keeping the books." One day, Joe's supervisor, knowing that Joe is the resident expert on accounting practices, presents him with an IBM PC and a copy of dBase II. Daunted at first, Joe digs in to the database, and after months of feverish activity, shows off his new accounting package.

No one is more surprised than Joe to find that the program actually does accounting. Still, he knows that it is not quite right, and it is always a few dollars and cents off at the end of the month. Over the next few years Joe works hard at fixing and improving the program, as well as writing numerous reports demanded by various departments. Finally the day comes for Joe to retire, and Sue, his assistant, is given the keys to the dBase program. Along with those keys Sue receives a "good luck" from Joe, but scant information about how the program works.

You already know the rest of the story. The program is in a hideous state of disrepair, but since Sue is as much a novice as Joe was, she is at a loss as to how to fix the application. If this story was unique we would simply sigh and say, "Oh poor Sue." But this situation happens on a daily basis across the computer world. Instead of pity for Sue, we often have to console ourselves.

Obscure programming practices are not limited to untrained business users. Programming students are often tempted with languages that invite them to write strange source code. One of the first languages I used in school was a flavor of BASIC found on the PDP 11/70 hosted operating system RSTS/E. This version of BASIC did not require whitespace to be placed between most language constructs. Therefore, it was possible to write the same four-line program shown earlier using a single, compressed statement.

FORI=1TO1000PRINTI,I+1NEXTIEND

It even allowed this reversed syntax.

PRINTI,I+1FORI=1TO1000

Imagine entire applications written in this compressed format! Because the interpreter focused on the extraction of known keywords from any statement, it allowed the programmer to write very unsightly code that did not run any faster than the equivalent code with whitespace included. Consider the following program.

10A$(I)=" "FORI=1TO9B$="-+-+-"C$="|"X=1R$=""T=0
20GOSUB500
25IFX=1THENPRINT"YOUR TURN:";ELSEPRINT"TRY AGAIN:";
30INPUTQ$P=INT(Q$)X=2IFA$(P)<>" "THENGOTO20
40X=1A$(P)="X"T=T+1
50GOSUB1000IFR$="X"THENPRINT"YOU WIN!"GOTO10
60IFT=9THENPRINT"DRAW"GOTO10
70M=INT(RND(9))IFA$(M)<>" "THENGOTO70A$(M)="O"
80GOSUB1000IFR$="O"THENGOSUB500PRINT"I WIN!"GOTO10
90GOTO20
500PRINT"BOARD LEGEND"FORC1=1TO3
510PRINTA$(((C1-1)*3)+1);C$;A$(((C1-1)*3)+2);
515PRINTC$;A$(((C1-1)*3)+3);
520PRINT"  ";((C1-1)*3)+1;C$;
525PRINT((C1-1)*3)+2;C$;((C1-1)*3)+1
530IFC1<3THENPRINTB$
540NEXTC1RETURN
1000RESTORER$=""FORC1=1TO8READT1READT2READT3
1010Q$=A$(T1)+A$(T2)+A$(T3)
1015IFQ$="XXX"THENR$="X"IFQ$="OOO"THENR$="O"
1020NEXTC1RETURN
1030DATA1,2,3,4,5,6,7,8,9,1,4,7,2,5,8,3,6,9,1,5,9,3,5,7

I am sure that you will soon figure out the purpose of this application. (See the answer at the end of this Preface just to be sure.) Can you picture an entire business application written in this style? Can you picture yourself being asked to fix such an application?

Visual Basic is a little more strict in the area of statement formatting, but it is still possible to write programs that are both internally (code) and externally (user interface) displeasing. When I was taking programming classes in school, I thought it was clever to write obfuscated code in this manner. ^[1] This feeling ended when, in my first programming job, I was asked to fix someone else's muddled application. From that point on I was committed to writing clear, concise, and readable code that was pleasing for both the programmer and for the user. This book is a guide to help you travel this same path. In this text you will find a clear differentiation between unprofessional programs—those that are aesthetically and logically annoying to both the user and other programmers that may review the code—and professional programs.

^[1] There is an annual contest where examples of obfuscated code written in C are submitted and judged for their obscurity. See the Web site at http://www.reality.sgi.com/csp/ioccc/ for examples of how not to write programs!