|
10 things i hate about visual basic
1. Line Continuation
I’ve been over this one many times with others, and the arguments just don’t wash. There is no rational reason for Visual Basic .NET to maintain the old "end of line is end of statement" madness that it inherited from the days of prehistoric computer languages. Yes, I realize that allowing free-flow lines implies using some kind of statement terminator or separator such as used by C#, Pascal, or any other modern language. The benefits are worth any small cost in programmer retraining. It only takes a few days to learn where to put the semicolons.
The number one reason I seriously dislike Visual Basic’s line-oriented syntax is that it makes some things impossible. For example, consider this code written in C#:
[C#]
MyMethod(
Param1, // description param 1
Param2, /* description param 2 */
Param3, // description param 3
Param4 // description param 4
);
This is a common coding style in C, C++, and C#--especially when calling Windows API functions that have many parameters.
You can’t write that in Visual Basic. You can do the multi-line function call using continuation characters, like this:
[Visual Basic]
MyMethod( _
Param1, _
Param2, _
Param3, _
Param4 _
)
But you can’t add the comments at the end of each physical line because the comment goes to the end of the line. So if you were to write:
MyMethod( _
Param1, ’ description of param 1 _
Param2, _
Param3, _
Param4, _
)
The compiler thinks that the statement ends at the end of the comment. The compiler doesn’t even see the line continuation character at the end of the comment. Instead, it sees the new line and thinks it’s reached the end of the statement.
2. No block comment operator
The example I showed above, of being unable to comment function parameters, could be fixed very easily if Visual Basic had a block comment operator. This is another place where Visual Basic shows its line-oriented, punch card roots. Like FORTRAN, COBOL, and most assembly languages, the only comment operator makes a comment to the end of the line. Unlike FORTRAN and COBOL, at least you don’t have to dedicate an entire line to the comment.
Every modern language has a block comment operator, and most have an end-of-line comment operator, too. For example, C# uses /* and */ for block comments.
Block comments are good for more than just getting around silly line-oriented limitations. They’re also handy for commenting out large blocks of code very quickly. You can do that in Visual Studio by highlighting the code to be commented and then selecting "Comment" from the appropriate menu. That puts a comment character at the beginning of each line. If you’re not using Visual Studio or some equally fancy editor, you’re out of luck and you’ll have to put a comment on each line yourself.
A block comment facility would be very useful.
Oh, and it’s about time to get rid of the REM comment reserved word, don’t you think?
The rules for converting types in Visual Basic .NET are confusing. One would think that, as a .NET language, the preferred way to do type conversion would be with the ToString and similar functions provided by the .NET Framework classes. Not so.
The online help for the conversion functions, http://msdn2.microsoft.com/en-us/library/s2dy91zy(VS.80).aspx, says:
As a rule, you should use the Visual Basic type conversion functions in preference to the .NET Framework methods such as ToString(), either on the Convert class or on an individual type structure or class. The Visual Basic functions are designed for optimal interaction with Visual Basic code, and they also make your source code shorter and easier to read.
In essence, they’re saying, "don’t do it the .NET way unless absolutely necessary." This is just another bit of evidence showing that Visual Basic is intended primarily for bringing old code to the .NET platform, and that Microsoft never really intended new code to be written in Visual Basic.
The existence of two sets of conversion functions results in confusion and a general misunderstanding of conversion by Visual Basic programmers--especially new VB programmers.
4. Type Casts
There are three different functions used to make type casts. Those functions are CType, DirectCast, and TryCast.
CType will perform just about any legal conversion. CType also can be defined as a conversion operator on a class or structure. CType thus becomes an overloaded conversion operator, which means that the behavior of calling CType on a class or structure is somewhat unpredictable.
DirectCast works on the principle of inheritance: in order for DirectCast to compile, there must be an inheritance relationship between the two types (the type being converted from and the type being converted to). DirectCast can work on any data types that have an inheritance relationship. It will not work to convert an Int16 to a Double.
TryCast is very similar to DirectCast in that it only works on objects that have an inheritance relationship. A further restriction is that it works only on reference types. The biggest difference, though, is not what types they support but how they behave on error. DirectCast throws an exception if the conversion fails. TryCast, on the other hand, just returns Nothing if a cast fails.
TryCast is more efficient on failure, although why a programmer would even care about the efficiency of an exceptional case is beyond me. I wouldn’t think that somebody would be doing so many typecasts that this would ever be an issue.
In any event, the three (or possibly more) typecast operators lead to even more confusion when converting from one type to another.
I used to be a big fan of Pascal’s with statement until I had to go back and modify some code in which I’d used it. The attraction of With, in Pascal and in Visual Basic, is its convenience and the time it saves in typing. For example, consider this code (myButton is a System.Windows.Forms.Button):
myButton.BackColor = Colors.Blue
myButton.ForeColor = Colors.White
myButton.Text = "Click me!"
Using the With statement, you can write:
With myButton
BackColor = Colors.Blue
ForeColor = Colors.White
Text = "Click me!"
End With
You can also nest With statements to any reasonable depth, as in:
With myContainer
’ blah
With myButton
’ blah, blah, blah
End With
’ more blah
End With
The compiler is smart enough to keep up with the scope of names within the nested With blocks. The question is, are you? Programmers aren’t used to thinking of name scoping in this way. If you run across a nested With statement that you didn’t write, or that you wrote six months before, you will be confused by it.
With is a typing convenience only. It has no effect on the efficiency of the generated code and will almost undoubtedly make your code more difficult to understand and modify. Don’t use it.
6. Event handling
How could Visual Basic’s event handling be broken when it just uses the .NET event handling mechanism? Because there are two different ways to hook up event handling in your Visual Basic programs. The .NET way involves creating delegates and writing AddHandler statements to hook up the events to the event handlers. Visual Studio .NET makes that very easy for C# programs, and the resulting code is easy to understand and modify.
But Visual Basic had to do it differently. Rather than write initialization code that sets up the event handling when an object is created, Visual Basic uses some behind-the-scenes magic to hook up the events. This magic is initiated by defining the object as responding to events (by adding the WithEvents modifier), and then adding the Handles clause to event handling procedures.
Both event handling mechanisms work, and it looks like they can even interact in some fashion. But I don’t know what would happen if I tried to call RemoveHandler on an event handler that was declared with Handles.
There should be only one event handling mechanism.
I understand that backward compatibility was important with Visual Basic .NET. Really, I do. But both of these "options" should have been removed from Visual Basic back in 1993 or so. There’s no excuse today for a language that will allow implicit narrowing conversions, implicit late binding, or variables used without first being declared.
There is absolutely nothing to be gained by maintaining support for these outmoded ideas. The few remaining bits of code that still depend on these options probably wouldn’t compile with the latest version of the compiler, anyway. Do you think that programmers who maintain sloppy constructs like that are even interested in dragging themselves kicking and screaming into the 1990s? Drop the support for ancient constructs.
8. Optional parameters
Another convenience feature that’s just syntactic sugar for no real benefit. That’s what overloaded functions and procedures are for. I see no clear benefit to cluttering up the language with optional parameters.
9. Old style function library
Just about every function listed in the Functions (Visual Basic) of the online help is there for backward compatibility with Visual Basic 6 or earlier versions. They represent the bad old days of procedural programming when Visual Basic was an ugly cross between a procedural language and an object-oriented language.
I realize that these functions must be supported in order to allow older code to run, but they should be defined in a separate namespace in a module that must be explicitly included in a project. Every one of those functions should be deprecated in preference to the .NET equivalent and programmers should be highly discouraged from using any of those functions. The Visual Basic team should set a release number (my suggestion is two releases from now) where all of those functions will be removed from the language.
Those functions that don’t exist in the .NET Framework should be re-implemented as .NET classes. For example, the Rate, PV, Pmt, and other financial functions should be moved into a .NET class and made accessible to all .NET languages. This was done for all of the basic math functions: they were moved to the Math class.
I think Visual Basic is that last language in the history of computing to insist on full evaluation of Boolean expressions. C has been shortcutting Boolean evaluation for 30 years. Borland started doing it with Pascal started doing it 20 years ago. Most other languages have supported shortcut Boolean evaluation either as the default behavior for 20 or more years. And yet Visual Basic still does things the old and dumb way.
What am I talking about? Consider this conditional:
If (A = B And C = D) Then
’ do something
Else
’ do something else
End If
In any rational language, the conditional statement is evaluated from left to right and the evaluation is short-circuited if the answer is known. For example, if A is not equal to B, then it’s obvious that the entire expression is false, so there’s no need to evaluate the second part. But Visual Basic does it anyway.
That doesn’t cause a problem in this case, but imagine if D in the above were replaced with a function call that had some side effect. I’ll grant you that the following is not very smart, but it’s possible:
If (A = B And C = D()) Then
I guess one could make the argument that by not shortcutting Boolean evaluation, Visual Basic makes sure that the same code is always executed. My only gripe is that Visual Basic is the only language in the modern world that behaves this way, and it’s something that will throw many programmers off.
If you want to shortcut Boolean evaluation in your Visual Basic conditionals, you need to replace And with AndAlso and Or with OrElse.
End of Rant
I feel better now that I’ve got that off my chest. As I said at the beginning, I’m not much of a Visual Basic programmer and I don’t particularly like the language. But I’m willing to learn. If you agree or disagree with anything I’ve said above, or if you have your own Visual Basic gripes, drop me a note. I’d be happy to discuss them with you.
|
