Read an Excerpt
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
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 thecreation 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 pi 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.
It even allowed this reversed syntax.
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.
25IFX=1THENPRINT"YOUR TURN:";ELSEPRINT"TRY AGAIN:";
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. 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 programsthose that are aesthetically and logically annoying to both the user and other programmers that may review the codeand professional programs.
Who Is This Book For?
This book is for everyone who cares about Visual Basic applications, and the development process surrounding these applications. Microsoft Visual Basic is very popular, outselling Microsoft's own C/C++ compiler by a factor of five to one. Many of these units are sold to weekend programmers with little or no training in programming practices. You can walk in to any major bookseller and see shelf after shelf of books with names like Learn Visual Basic in Your Sleep and Visual Basic in 21 Minutes. These books are great for learning the usage and syntax of Visual Basic, but they often fall short when it comes to training the eager developer how to program well. The Visual Basic Style Guide is written for the Visual Basic programmer who wishes to enhance his or her professional and technical programming methods and style. If you are such a programmer, read on!
Writing professional Visual Basic programs does take effort, lots of effort. Still, effort alone will not bring about the quality that you seek. This book contains lists of guidelines for writing good Visual Basic programs. Yet more than that, it promotes an attitude, an environment of the mind in which healthy Visual Basic programs are formed.
The Visual Basic language now reaches out into other areas of software development. With the advent of Visual Basic for Applications and Visual Basic, Scripting Edition, more and more programmers are relying on Visual Basic for their many software solutions. The Visual Basic Style Guide is designed for use with each of the flavors of Visual Basic.