Home > Articles > Programming > Windows Programming

.NET Reference Guide

Hosted by

Toggle Open Guide Table of ContentsGuide Contents

Close Table of ContentsGuide Contents

Close Table of Contents

10 Things I Hate About Visual Basic

Last updated Mar 14, 2003.

I’ll preface this by saying that I stopped programming in Basic in about 1983. Since then, I’ve written Basic programs only under duress, and not very frequently even then. Having to create Visual Basic examples of my .NET code is perhaps the most distasteful thing about writing this column.

The following are 10 of the things I find most annoying about using Visual Basic .NET. Your mileage may vary.

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?

Save To Your Account