Visual Basic in Your Face: Notes from the Real World [Paperback]

Visual Basic is killing programming. Years ago, programming was considered difficult and people had to be taught how to do it. There were people who learned on the job, of course, but generally they were enthusiasts who had the wherewithal for programming and just needed the guidance of an experienced mentor to bring it out. But with the advent of Visual Basic, everyone who can work a mouse is suddenly a programmer.

This book puts programming fundamentals on the Visual Basic agenda. From the pages of keysound.com comes a collection of essays founded on the experiences of a professional writer of Visual Basic. The result is an uncompromisingly honest appraisal of Visual Basic’s strengths and weaknesses, and an invaluable source of wisdom about the 'nuts and bolts' of cutting VB code.

"It’s good to see a book that is based on real-world experience, rather than a re-write of the manual."

- Matt Nicholson, Editor, DNJ

"Written from the heart by someone who’s been there, seen that, noted that it didn’t work, worked out why it didn’t work, fixed the problem, re-coded it, seen it work and then moved on to the next problem. This is experience and 'hard knocks' distilled, and I consider it an essential read."

- Peet Morris, Head of Technology, The Mandelbrot Set

"When I'm looking to get into the guts of VB, Mark Hurst is one of the first people I think of. His articles are concise, elegant and reliable. But don't take my word for it."

- Graham Parker, Chairman, VB User Group

Mark Hurst has been a programmer for twenty years, initially in C and Pascal, and then C++ and Visual Basic. He contributed to both editions of Advanced Visual Basic, written for Microsoft Press by The Mandelbrot Set, and he was Technical Editor on Using Visual Basic 5.0 and Special Edition: Using Visual Basic 6.0, both published by QUE. Mark has lectured on Visual Basic and he was a speaker at VBITS 1996, where he presented a talk on source code management.

Chapter 14: The Great Hungarian Prefix Swindle (excerpt)

So why do we need type prefixes on variable names? Well, there are some precedents, chiefly from weakly-typed languages such as C. In C you can assign any variable to just about any other variable and the compiler won´t mind. You´ll often get warnings about incompatibilities, but these are implementation-dependent and chosen by the compiler vendor rather than the language definition. C has other pitfalls too, including the array/pointer equivalence and the traditional idiom of coercing freely between pointers and integers. These features add up to a very powerful language, but the opportunities for error are enormous.

In the kind of `bare metal´ programming environment offered by C it´s so easy to lose track of what kind of data a particular variable holds that the use of type prefixes is a useful reality check. But what about Visual Basic? VB does have some annoying type coercion problems, although they aren´t in the same league as the ones we find in C (we can´t assign an object reference to an Integer variable, for example). Nevertheless, coercions are rife, and the VB literature doesn´t help by teaching beginners the kind of sloppy coding that relies on them. Perhaps there really is a case for type prefixes in VB?

A fundamental principle of programming is to make the code easy to understand, and one of the ways to do that is by keeping the focus as local as possible. The more pages your reader has to flip to assimilate the details of what he´s reading, the less likely he is to understand your code. By incorporating a type prefix on the identifier itself, you are cutting out some of this page-flipping.

But wait a minute, your reader is flipping pages? This may have rung true for C programmers in the eighties, but it´s pretty unusual to find anyone debugging Visual Basic code on paper. The Visual Basic IDE is designed for browsing code, and since version 5.0, the identifier lookup (Shift-F2) function has been so good that we can almost always find out a variable´s type with a single keystroke. This simple fact defuses one of the most compelling reasons for using type prefixes.

But even if we assume that type prefixes add value to Visual Basic code, they are becoming increasingly irrelevant as we move towards programming with objects. There are two main reasons for this. First, it is usual to omit type prefixes from public interfaces, so the more object types (classes) you programs rely on, the smaller the proportion of your code that will feature type prefixes. This idea also applies to named parameters, both in public interfaces and private ones (depending on where you draw the line).

The second reason that type prefixes are diminishing in usefulness is that they are inevitably applied only to intrinsic data types (Integer, String, and so on). This means that as we begin to use more classes, user-defined types and enums, fewer and fewer of our variables warrant useful type prefixes and most end up carrying a generic `o´ or `obj´ prefix. The argument, then, is this: there are so many exceptions to the use of type prefixes that at some point we´ll find ourselves writing more code without prefixes than with them. Even if this isn´t so, code that uses type prefixes inconsistently undermines the intellectual manageability we are striving for.

The questions we need to address are: do type prefixes give us any benefits, and, if so, what are those benefits? All other things being equal, any prefix simply obscures the identifier name, and I'm no longer convinced that there are significant benefits to type prefixes in VB. Take controls, for example. We routinely prefix our control names with a suitable tag, yet this is nothing to do with enforcing data typing. Nine times out of ten, code that refers to a control simply sets a property or invokes a method - if the control doesn't support the property we're trying to assign, either we'll get a compile-time error, or, if we´re assuming the default property (in which case we deserve all we get), VB may do a coercion. So what´s the point?

There are only two reasons I can think of to prefix a control name with a tag: (i) to ensure we don't assign a reference to the control to an incompatible variable, and (ii) to give us a clue to the control type when we're browsing the code. We can discount (i) because it's only applicable in the rare situation where we're using As Object to fake polymorphism (or for other reasons, such as laziness or incompetence), and (ii) is tantamount to admitting we're going to choose poor names.

Something else I´ve never seen acknowledged is that what we call 'hungarian' notation has very little to do with what Charles Simonyi proposed in his original paper. Taken as a whole, Simonyi's coding conventions are aimed at producing terse, precise names from a pool of standard words and abbreviations - ie. they are ABSOLUTELY NOT about merely adding type prefixes to conventional variable names. Simonyi´s `hungarian´ system is designed to be so deliberately inflexible that, ideally, two different programmers coding the same program would come up with exactly the same variable names. This is anathema to the conventional wisdom of 'choosing meaningful variable names', as is his suggestion that we should use naked tags to name certain classes of variables (loop counters, for example).

Crucially, Simonyi´s claims for the effectiveness of his coding scheme depend on two features that are missing from any VB variation I've ever seen: (i) that a tag (prefix) is chosen for every programmer-defined data type (enum, UDT or class in VB), and (ii) that the scheme is applied without exception. Interestingly, in Code Complete Steve McConnell identifies point (i) and concludes that any scheme which doesn't do this results in 'a convention of little value'. He also notes that hungarian notation 'encourages lazy, uninformative variable names'.