JANUARY 19100, EXE MAGAZINE
This article has brought me more comeback than any other, drawing in many passionate emails from both sides of the argument.
Interestingly, it contains a whopping bug, caused by my changing of my code after Id tested itI over-egged the pudding to dramatise a point. I stand by the complaint I was making, but the example wont compile.
None of my pro-VB correspondents pointed out this error. Instead they have concentrated on irrelevancies; for example noting that it is possible to change the behaviour of VB6s editor to overcome the difficulty indicated in point 12.5.
As is often the case, Microsoft has had the final say. When it designed VB.NET, the successor of the tool considered here, it chose to fix most of these issues.
Thirteen Ways to Loathe VB
Verity Stob has recently been press-ganged into a Visual Basic project. For the benefit of other programmers who may be brought down in this way, she has prepared an executive summary of her experience.
1. Procedure and function call. This area of BASIC has come on in leaps and bounds. Whereas in the bad old days you had to use GOSUB, these days you have subs (subs is the preferred babyspeak for what grown-ups call procedures or void functions) and functions. You write
Subname Param1, Param2
to call sub Subname and
Result = FuncName(Param1, Param2)
to call function FuncName. Notice the useful difference in syntax, with and without parentheses, which serves more purposes than I can describe. It is of course a syntax error to write
but the good news is you can write
to call a function and ignore its return. However, if Param1 or Param2 are reference parametersand they will be unless you have specifically demanded value parametersthey will be treated in this specific case as value parameters, and any assignment to them discarded on exit from FuncName.
Obviously the syntax
Call FuncName(Param1, Param2)
fixes this, and causes Param1 and Param2 to be treated as reference parameters.
2. Variable declaration. This is achieved using the intuitive keyword Dim. To declare an integer I write
Dim I As Integer
To declare a whole load of integers write
Dim I, J, K, L As Integer
Actually (haha got you!) this doesnt work. This declares I, J, and K as variants and only L as an Integer. This almost never matters, except quite often.
3. Calling functions and accessing arrays. In most languages you can distinguish between a call to function F with parameter 3 and a reference to array F index 3 because one is written F(3) and the other F. In Visual Basic they are both written F(3). Yes.
4. Another thing about arrays. The index of the first element is 0, unless it is set to 1 by a directive.
5. But there are also collections, modern object-oriented versions of arrays. And the first element of these is usually 1, unless it happens to be 0. Sometimes it is 0 and sometimes it is 1, depending on where you found it. Do you feel lucky, punk? Well, do ya?
6. Did I mention object-oriented back there?
7. Initialisation. This area of BASIC has come on in leaps and bounds. Whereas in the bad old days you had to use a completely barbaric mechanism based on the keywords DATA and READ, this has now been swept away. The following fragment illustrates the modern way to initialise an array in code:
Dim A(20) As Double
A(0) = 4.5 ' May work, may notwho can tell?
A(1) = 4.71
A(2) = 4.82
A(3) = 4.92
You get the idea.
8. Arrays of constants. No such thing. Anyway what would you do with em if you had em?
9. The type Integer declares a 16-bit integer. Thats right, sixteen bits.
Yes I am using the latest version. Unbelievable, isnt it? Lets have a big warm EXE welcome back to code that dies suddenly around the 33k mark.
10. Assignment. This area of BASIC has come on in leaps and bounds. Whereas in the bad old days you used the = operator for assignment, preceding it with LET if you were a fusspot of the first order, these days you use the = operator for assignment, preceding it with Let if you are a fusspot of the first order. Or Set if its an object. Which is compulsory not optional.
11. Logic. This particular language is supposed to be easy and intuitive, so heres a test for you. Suppose that Check1 is a checkbox on a form, and you execute the code
Dim b As Boolean, c As Boolean
b = Check1.Value
c = Not Check1.Value
Then b as expected will contain True if the checkbox is checked and False if the checkbox is unchecked. What do you think c will contain? (Clue: always True. No, really.)