Things I Would Change in VB

VB is a great language, but I still think it has room for improvement. For example, there are far too many keywords, some of the keywords are confusing, and some keywords have too many overloaded meanings. There are also problems with the IDE that should be addressed. More than any other language, VB has always been about a partnership with the IDE, and this functionality is crucial for its ease of use and power.

Language Changes

Declare instead of Dim for variable declaration

The use of the keyword ‘Dim’ for variable declaration is an historical artifact of Basic. A more descriptive name would be ‘Declare’ which is already a VB keyword, but used for a feature of dubious value. Here are some examples, of what I would prefer, and I’ll continue to do so in subsequent examples:

Declare x,y,z As Integer 
Declare names(1 to 10) As String 
Declare teams() As String = GetTeams()
Too many uses of parentheses

I personally find it confusing that parentheses are used for expression grouping, array declarations, indexing, and function calling. I think it would be more readable if we used brackets for indexing and arrays.

Declare names[10] As String 
names[0] = “Justin” 
names[(x + (y \ 2))] = “Michel” 
Console.WriteLine(“Name = “ & GetNamePrefix() & names[2])
GetType, TypeOf

It doesn’t seem like we should need both of these keywords. One option would be to use TypeOf (T) for retreiving the type of a class. I think this is more consistent with VB’s readable syntax. Even better would be to support accessing a Shared GetType method or read-only Type property on any type, which would eliminate the need for a keyword in this use case completely. Best might be to allow the type name itself to be used.

Declare t As Type = FileStream.GetType()


Declare t As Type = TypeOf(FileStream)


Declare t As Type = FileStream.Type


Declare t As Type = FileStream
Is, IsA, and TypeOf

The current keyword "Is" should be used to compare for identity only. If used with two reference types then it returns true if both refer to the same exact object. If used with value types then it returns true if both have the same value. Basically, I’m suggesting elimination of “If TypeOf X Is Y Then” as a special case, although if we retain TypeOf as outlined above, then “If TypeOf(X) Is Y Then” and “If TypeOf(X) = Y Then” are both legal and equivalent.

A new keyword IsA should be introduced to allow easy comparison of types. A IsA B should return true if A is the same type as B, A derives from B, or if B is an interface implemented by A.

Declare A, B As Foo 
A IsA Foo ' returns true 
Foo IsA A ' won’t compile, because left hand side is a type. 
A IsA B ' won’t compile, because B is an object. 
A IsA B.GetType() ' returns true

It’s also confusing that Is must be used in a Select expression. It seems like the extra keyword should be unnecessary.

Select age 
Case 5 To 10, 12 To 15 
Case < 5, 13, 16, > 80 ' No need for “Case Is < 5, 13, 16, Is > 80” 
Case Default 
End Select 
Too many conversion keywords

I think all of CBool, CByte, CChar, CDate, CDbl, etc. can be eliminated by replacing them with a single Convert function. It would behave exactly the same as the current keywords.

Declare d As Double = 3.14 
Declare x As Integer = Convert(d, Integer) 

— but also allowing —

Declare x As Integer = Convert(d) 

My proposed syntax is a little more verbose, but eliminates 15 keywords, some of which can be hard to remember. It also supports implicit detection of the desired type if possible, as in the example above where it can see that the target of the Convert is an Integer, and saves you the trouble of explicitly stating that.

I would also allow a third parameter to Convert for specifying the type converted from. This can be useful when the source type is not always obvious, and when you want a warning when source type is refactored.

Declare x As UInt32 = Convert(GetAge(), From := UInt64) 

This takes advantage of current named argument syntax to allow both implicit detection of the To type and explicit specification of the From type. If the GetAge function is someday updated to return a Int64, then the code would no longer compile, preventing a possible bug when dealing with negative values.

DirectCast too verbose

This keyword is unnecessarilly verbose. Fortunately there is already an intuitive and logical replacement already in the language.

Declare x As Object = GetFoo() 
Declare y As Foo 
y = x As Foo 

The As keyword is already used to declare the type of an object, and the above syntax should be obvious in meaning. As with DirectCast, if x is not a Foo, then an exception would be thrown.

It would also be nice to allow this syntax to be used when it’s known that the source and destination types differ. In this case, “As” would be equivalent to Convert.

Declare d As Double = 3.14 
Declare x As Integer = d As Integer 
Eliminate TryCast

The use of TryCast doesn’t really add any value. Instead of:

Declare x As Foo = TryCast(y, Foo) 
If x Is Nothing Then 
End If 

you could just use:

If y IsA Foo Then 
  Declare x As Foo = y As Foo 
End If 

The compiler should be able to figure out how to make the latter syntax just as efficient as the former.

No need for CType

There should be no need for this keyword, which is kind of a hybrid between casting and conversion. This should be replaced by either As or Convert. The use of CType for defining conversion operators on a class would use the keyword Convert instead.

Nothing vs. Null

The VB concept of Nothing is almost always referred to as Null in other languages, and even within much of the VB community (Probably because of SQL). Having a separate term for such a common concept is just confusing for users old and new.

Declare x As Foo = Null 
Assert(x IsNot Null) 
Assert(x = Null) 
No need for AddressOf keyword

Nowhere else in VB is the notion of pointer or address exposed, and it’s likely that AddressOf doesn’t really return an address anyway. We could just use the Function or Sub keyword in place of AddressOf.

From the examples in AddressOf documentation:

AddHandler Button1.Click, Sub Button1_Click 
Declare t As New Thread(Sub CountSheep) 
Add the ability to Define aliases

The C++ typedef keyword is often useful for writing maintainable code, and sometimes C++ references are handy in situations other than parameter passing. I propose that a new Define keyword could provide this functionality for VB in an intuitive way.

It can allow you to enhance readability. For example, by defining a new IntList type we save typing and enhance readability whereever List(Of Int) is used. This becomes more valuable with more complex generic types.

Define IntList As List(Of Integer) 
Declare v As IntList 

It can also be useful for changing a type without having to update all the code, or to allow conditional compilation to use different types.

#If SafetyEnabled Then 
  Define MyInt As SafeInteger 
  Define MyInt As Integer 
#End If 

Define is already partially available with Imports. I would remove the ability for Imports to define new aliases and use the Define syntax instead.

Imports Con = System.Console 


Define Con As System.Console 

This keyword could also be useful for defining aliases for other things besides Types.

Sub Foo 
  Declare aReallyReallyLongName As SomeType = GetSomeType() 
  Define s As aReallyReallyLongName 
  Define sm As s.SomeReallyLongMethodName 
End Sub 
More flexible Imports

I’d like to Import a symbol within small scope. I see no reason why this couldn’t be allowed anywhere instead of only at the top of a file.

Sub Log() 
  Imports System.Console 
End Sub 
No need for Delegate keyword

We should just be able to define a delegate type like any other.

Define Sub OnClick(ByVal e As EventArgs) 
AddHandler Button1.Click, Sub OnClick 
Public Event As OnClick 
Remove Alias, Ansi, Auto, Declare, Lib, and Unicode

These keywords for declaring access to external functions make it marginally easier to access external Win32 routines, but cause unnecessary clutter in the language, making it that much harder to understand. They are also unnecessary, because it’s not much harder to just use the DllImport attribute.

Consider removing keywords for basic types

The CLR already defines nice unambigous names for all the basic types such as Byte, Integer, Short, Long, etc. It might be better just to use those, and eliminate the unnecessary keywords from VB. Most of the VB keywords are the same as the names defined in System anyway, so this wouldn’t be that onerous. The proposed Define feature could even provide easy compatibility for old code.

No need for the Call keyword

In VB you can call a subroutine by saying “Call Foo”, but you can also get exactly the same behavior by saying “Foo()”. I don’t see any benefit to the former syntax, and it adds yet another unnecessary keyword to the language.

Select instead of “Select Case”

There’s no need to support an optional Case keyword in the first line of a Select statement. We should just standardize on the following syntax, and eliminate a little more clutter from the language.

Select age ' vs. Select Case age
Case 0 To 20 
Case 21 
Case 25, > 30 
Case Else 
End Select 

There are currently some basic types that have no syntax for literal declaration such as Byte. There are also some type such as Char where the literal syntax is unintuitive. A better character literal might use the back-tick (e.g. `c`).

Eliminate the colon

One of the strengths of VB is its readable line-oriented syntax. The colon operator allows you to subvert this. Eliminating this would help keep VB code readable to all VB programmers.

The other use for the colon is to declare labels for GoTo statements, but I’m also proposing elimination of GoTo for VB.

Eliminate the underscore

Similarly the underscore is a crutch that should not be needed. Code should either rely on wrapping in the IDE, or introduction of temporary variables to make code more readable.

However, to make this work, we need to eliminate some of the most egregious causes of lengthy lines. The UsesAttribute keyword fixes one such area, new syntax for Implementing interfaces fixes another, and the proposed Define keyword another.

Bring Back the underscore

Instead of using the underscore for line continuation, I would use it to disambiguate VB keywords that match symbols. Currently the [] brackets are used for this purpose, but I think those work better for array access as stated previously, and prepending an underscore seems a more intuitive solution. Hopefully the elimination of many keywords will make the need for disambiguation much less prevalent.

Remove the \ symbol

Although integer division is probably fairly frequently used, I find the inclusion of two separate division symbols confusing. Integer / Integer, should leave the arguments as integers, while Int / Float and Float / Div Int should convert the result to a floating point type. Anything else can be handled by explicit conversions and/or separate math library functions. It would also be helpful if the IDE would colorize integer types differently than floating point.

Eliminate If … Then … Else … Statements

One of the primary values of VB is its line-oriented nature. I was completely unaware that the current VB allows If Then Else on a single line without an End If. This should not be allowed, as it subverts the nature of VB, by allowing a tiny syntactic convenience with far greater potential for misuse than valid use cases.

For example, this currently compiles, and I don’t think it should.

If x > 0 Then Return “>” Else Return “<=” 
Introduce a short-circuiting ternary expression

One of the problems with the C ternary expression is that the default case is separated from the context by the boolean expression. For example, if I want to Trim() only a non-null string in C#:

String trimmed = s != null ? s.Trim() : “”; 

Notice how the code we really want to write “String trimmed = s.Trim();” is very different from the code we have to write to handle the null.

I think VB has the opportunity to make this common expression more readable by reordering the “arguments” to allow:

String trimmed = s.Trim() ? s != null : “”;

Or in VB:

Declare trimmed As String = s.Trim() IIf s IsNot Nothing Else “”; 

Other examples:

If a = (b IIf b < 5 Else 5) Then 
If a = (b IIf b IsNot Nothing Else GetDefault()) Then 
Foo(a, (x IIf a > 0 Else GetDefault()), z) 
y = 10 IIf x Is Nothing Else x.Foo() 
Introduce UsesAttribute

Instead of overloading the < and > operators for applying attributes, I propose we add a new keyword to make this feel more natural in VB, and to eliminate one of the major needs for the underscore line continuation character.

Sub Foo(ByVal s As String, ByVal n As Int32) 
  UsesAttribute Conditional(“A”) 
  UsesAttribute WebMethod 
  ' Body of subroutine 
End Sub 

Class SomeService 
  Inherits Foo 
  Implements Bar 
  UsesAttribute WebService(Namespace:=”blah”) 

  Sub New() 
  End Sub 

  Sub Calculate 
    UsesAttribute WebMethod 
  End Sub 
End Class
Unweildy Interface-based polymorphism

A strength of VB is its readable English keywords, but in practice this can sometimes get out of hand.

Public Interface Shape 
  Function CalculateArea(ByVal X As Double, ByVal Y As Double) As Double 
End Interface 
Public Class RightTriangleClass 
  Implements Shape 

  Function CalculateArea(ByVal X As Double, _ 
    ByVal Y As Double) As Double Implements Shape.CalculateArea 
    Return 0.5 * (X * Y) 
  End Function 
End Class 

In general, any time the underscore has to be introduced to allow a logical line to continue on the next physical line, we see an area for improvement. The following would be a much nicer syntax for the above, with the option of reverting to the really verbose syntax only when there’s a conflict, or when you want to change the name of the interface.

Public Class RightTriangleClass2 
  Implements Shape2 

  Function Implements CalculateArea(ByVal X As Double, ByVal Y As  Double) As Double 
    Return 0.5 * (X * Y) 
  End Function 
End Class 

There’s no need for this keyword, as you can get the same effect by assigning Null. The Erase statement supports a variable number of arguments, but the limited utility of this is not worth the introduction of a keyword. Instead, if this functionality is important, then it would be more useful to allow ParamArray to use ByRef making it easy to implement Erase as a user function, as well as other possibly useful functions.

ReDim and Preserve

This functionality seems easy enough to reproduce with a few small functions, possibly added to the Array class.

On, Error, Resume

These keywords are no longer necessary in a modern VB. We now have exception handling, and these just clutter the language in the name of reverse compatibility.

No public fields in Class types

By eliminating the capability to create Public members of a class type, we can use the following syntax to declare simple properties.

Class Foo 
  Public ReadOnly name As String 
  Public age As Int32 
End Class 

More complex properties could revert to the older syntax using Property. Public fields would still be allowed in value types.

No more Set or Get

“Set” is just too valuable to waste on a keyword. I’d rather have a System.Collections.Generic.Set for holding sets of objects. When declaring properties we can just take advantage of the fact that the mutator is always a Sub, while the accessor is always a Function. Then we no longer need the two keywords.

Private myName As String 
Public Property Name As String 
  Sub (ByVal s As String) 
    myName = s 
  End Sub 
    Return myName 
  End Function 
End Property 
Goodbye Goto

Let’s be the first language to discard goto. CS programs usually go to great lengths to teach students that goto is almost always the wrong solution. The variety of languages available on the .NET platform means that some languages like VB and C# can eliminate goto, while others (C++?) could keep it.

Generic RAII scope

The Using statement is one useful way to ensure that object are disposed correctly, but sometimes it can be cumbersome, and can lead to unnecessarilly deep nesting. It would be useful to introduce Scoped variables to handle this more cleanly in some cases.

Sub Test 
  If blah Then 
    Scoped x, y, z As Connection 
    ' x, y, aand z are disposed here 
  End If 
  If blahblah Then 
    Scoped lock1 As Mutex = … 
    Scoped lock2 As Mutex = … 
    ' lock2, lock3, … are released 
  End If 
End Sub 
Eliminate SyncLock

More general Scoped and Using keywords can replace the need for this.

Modules, Namespace, and Shared Class members

I find it a little confusing that all these exist. Maybe this could be simplified by allowing global functions in a Namespace as an alternative to Modules, or eliminating the Namespace keyword entirely and using the Module keyword for this concept.

No Next

It would make VB easier to understand and more consistent if “Loop” were used to end For Loops. This is consistent with the other loop variants, and makes it clearer what’s happenning.

Eliminate While Loops

Do While … Loop should be sufficient without the need for While…End While. This doesn’t actually save keywords, but simplifies the language by eliminating an unnecessary and more verbose syntax for while loops. The IDE could allow leaving off the Do keyword, and filling it in automatically.

Simplify Continue and Exit

Continue is followed by Do, While, or For to indicate which type of loop to continue. This added flexibility is unnecessary, and Continue should just jump to the top of the current loop.

For I = 1 to 10 
  Do While blah 
    If x Then 
    End If 

The above, would simply restart the Do While loop when x is True. If you really need to restart at the beginning of the For loop then the code can be refactored into multiple methods or some other approach.

Similarly, only “Exit Loop” should be supported in the future. Exiting a sub, function, or property is accomplished with “Return”, and exiting a Select is unnecessary.

ElseIf is inconsistent

"For Each" and "End If" use two separate words, so Else If should also.

Declare x As Object

It would be nice if the “As Object” part of the expression were optional even when Option Strict and Option Explicit are enabled. The default value for any type would be Object. So I would advocate:

Declare x

More flexible Options

As fancy new features such as Lambda Expressions and Closures are added to the language, we may want more flexible control over the options. For example, we may want to turn Strict and Explicit off for Lambdas, while leaving them on for everything else. We might also want finer control of the scope for these options, perhaps turning off Option Strict within the scope of a single Function.

Rather than have keywords for these two statements, just introduce new VB attributes.

StrictMethods(on|off) – controls whether late binding is allowed

StrictConversions(on|off) – controls whether Int64 auto-converts to Int32

ExplicitLambdas(on|off) – controls whether lambda expressions require types


Consider eliminating or extending With

By allowing an empty with statement we can introduce an artificial scope, which can sometimes be useful to avoid having too many variables in scope. Usually it’s better to split such a method into separate subroutines, but this can sometimes make an algorithm harder to understand.

  Declare x As IntegerEnd With 

‘ x is not in scope

It would also be useful to assign an alias for the With object.

Sub Foo() 
  With f = GetEmployee.Name.FirstName 
  End With 
End Sub 

However, this is not so necessary with the proposed Define keyword:

Sub Foo() 
  Define f As GetEmployee.Name.FirstName 
End Sub 
RaiseEvent unnecessary

This keyword is similar to Call, and is also unnecesary, when the obvious syntax of calling the event as a function would be more intuitive.

Event LogonCompleted(ByVal UserName As String) 
Sub Logon 
End Sub 
AddHandler, RemoveHandler

Using language keywords for these is confusing. The C# syntax might be fine, or VB could automatically allow any Event/Delegate to have implicit Add/RemoveHandler methods. Note that += should NOT be used, because we’re appending to the list of handlers, therefore &= concatentation is more appropriate.

Public Event LogonCompleted(ByVal UserName As String) 
Sub OnLogon(ByVal x As String) 
End Sub 
Sub New 
  LogonCompleted &= Sub OnLogon 
  LogonCompleted.AddHandler(Sub OnLogon) 
End Sub 
No more REM, and add comment blocks

There’s no point in having two mechanism for line comments, although it might be useful to introduce a multiline comment.

‘’’ Anything between here

and here

is a comment


No more implicit return variable for functions

Having two ways to return a value from a function just adds complexity to the language with very little benefit. At best it saves a line of code or two to declare the return value and return it, but often modern programs don’t (and shouldn’t) declare a single return value anyway.

Rename Shadows

The description for this feature, provides the answer for what the keyword should be. “Specifies that a declared programming element redeclares and hides an identically named element, or set of overloaded elements, in a base class.” By renaming the keyword to Hides, it becomes more accessible to a new or infrequent VB programmer.

Hides should also be useable to explicitly state desired behavior.

Sub Foo 
  Declare I As Integer 
  If blah Then 
    Hides I As String 
  End If 
End Sub 
No End or Stop

The Stop keyword should be removed from the language. There’s no need for this to be a language-specific feature, as it’s easy enough to use the portable System.Diagnostics.Debugger.Break() method.

The End keyword (that halts the process) should also be removed for similar reasons. Normally, you would either let an uncaught exception percolate up and kill the process, or you could call Process.Kill() possibly followed by Process.WaitForExit().

Allow automatic assignment of Arrays to variables

Python has some useful syntax for working with Tuples. VB could add some of the same convenient syntax for working with arrays.

Allow automatically assigning array values to variables. The a,b, and c variables would be filled with the first three values from the array.

Function Foo() As String() 
End Function 
Declare a, b, c As Integer = Foo() 

Also, allow more flexibility for array initializers.

Declare x, y, z As Integer = 1, 2, 3 
Add Slices

Python has the useful ability to access a subset of any List, String, or Tuple. VB could support similar syntax without complicating the language much.

Declare s As String = “Hello World” 
s[0] equals ‘H’ 
s[0 To 2] equals “H 
s[-1] equals ‘d’ 
s[-4 To -2] equals “orl” 


Remove Mid

By allowing slices to be assigned, you make a more flexible Mid that is also more intuitive to read.

Eliminate need for GetChar

A single element slice should automatically return a Char instead of a one element string. The new `a` character literal should be equivalent to “a”[0].

No need for { } array initializers

VB should be able to figure this out without the braces, and should be able to parentheses to make the association explicit where it would be ambiguous.

Declare x, y, z As Integer = 1, 2, 3 
Declare x[] As Integer = 1, 2, 3 
Declare x[][] As Integer = (1, 2, 3), (1, 2, 3) 
Declare x[2, 2] As Integer = (1, 2, 3), (1, 2, 3) 
Sub Foo(ByVal a() As Int32, ByVal b As Integer) 
End Sub
Foo((1, 2, 3), 4) 
Array Bounds vs Last index confusion

I still find the syntax choice for array declarations confusing, and it doesn’t help much that the To keyword is supported. (Unless the IDE were to add it automatically.)

Declare x(5) As Integer should create a 5 element array with a lower bound of zero.

This use of the To keyword should be removed again, because allowing flexible lower bounds just makes arrays more confusing to work with. For those who want or need explicit lower bounds, a generic BoundedArray class could be provided.

Automatic ToString when using concatenation

One of the benefits of having separate unambiguous concatenation operator ‘&’ in VB, is that it can automatically convert its arguments to strings.

Declare I As Integer 
Declare f As New Foo 
f & I & “blah” 
I & f & “blah” 

This is currently possible only by explicitly implementing the concatentation operator for Foo, but it requires providing an implementation for every possible valuetype, or inefficiently overriding for just Object, forcing boxing. This could be partially helped by allowing generic operator overloading, but that would still be far too tedious for the common case. It might even be desirable to remove operator overloading for the ‘&’ operator, and instead forcing that to always represent string concatenation and be handled automatically.

Separate operator for assignment and equality

One of the keys to VB’s ease of use is that it doesn’t allow assignment statements to return a value. Unlike other languages, you can’t do:

Declare a, b, c As Integer 
a = b = c = 5 

One result is that VB can always tell from the context whether ‘=’ is meant as an assignment or a comparison. This is actually a valuable feature, because it saves typing and prevents a common error from other languages.

What I propose is that we use the := operator that is already used for named arguments as the only allowed assignment operator, and have the IDE automatically change ‘=’ into ‘:=’ as it’s parsed in the same way that it automatically changes “Endif” into “End If” and other similar transformations. One benefit is that we get immediate visual feedback that VB understood what we meant when it makes the transformation.

For Loop should iterate only over the specified range

The following expression currently increments M, then checks to see if it’s less than 5.

For M = 0 To 5 

This is confusing given the VB syntax, because the syntax seems to imply that “M” will only take on the values 0, 1, 2, 3, 4 and 5, but it will actually be 6 after the loop.

Besides being confusing, it can easily lead to infinite loops if the incremented variable overflows. If overflow checking is enabled, then instead of an infinite loop, you get an exception. Either is unwarranted.

Eliminate MyClass

I find this keyword hard to remember, and I’d just like to be able to use the name of my class to be explicit when necessary.

Class Foo 
  Protected Overridable Sub Bar() 
  End Sub 
  Public Sub CallMyBar() 
    Foo.Bar() ' calls our own Bar 
    Bar() ' calls the bar of our most derived class 
  End Sub 
End Class 
Allow alternate spellings for Overridable, NotOverridable

It would be consistent with the English language to also allow Overrideable and NotOverrideable as synonyms.

Eliminate Type Characters

Old style code that used type characters should no longer be supported.

Function StrFunc(ByVal x&, ByVal y$, ByVal z#) 

They also shouldn’t be allowed for literals.

Literal DateTime values should still be supported however, because they’re useful, and easier to read than alternatives.

Declare d As DateTime = #11/11/1970 13:32# 
Literal Values for every type
tmp = 42    ' Int32 
tmp = 42UI  ' Unsigned Int32 
tmp = 42L   ' Int64 
tmp = 42UL  ' Unsigned Int64 
tmp = 42S   ' Int16 
tmp = 42US  ' Unsigned Int16 
tmp = 42B   ' Byte 
tmp = 42SB  ' Signed Byte 
tmp = 42.5F ' Float32 
tmp = 42.5  ' Float64 

Currently, only L, UL, and UI are supported

Eliminate Assembly, Option Compare, Binary, and Text Keywords

We shouldn’t have to use language keywords (even unreserved ones) to change these behaviors. The IDE or command line tools should be able to handle it when necessary, or UsesAttribute.

Option Compare may be completely unnecessary, as String already provides explicit control.

Add missing Volatile keyword

This should have the same meaning as other languages.

GoSub, Let, and Wend

These have been deprecated long enough and can all be eliminated if making the kind of sweeping changes I’m advocating.

Bring Back Variant

Option Strict is currently used for many related features, such as implicit type conversions and duck typing. However, it might be even better to reintroduce the Variant keyword to allow duck typing for individual identifiers. This would work even with Option Strict enabled.

No VB-specific extension libraries by default

I’d like to be able to write portable code that doesn’t rely on VB-specific libraries. I don’t care about access to legacy APIs that are currently in the Microsoft.VisualBasic namespace. Any features, such as the Convert function that are needed should be available without having to pull in other baggage as well.

Lambda Expressions

This feature is partially planned for the next release, but I’m afraid it’s going to allow code that is too cryptic and terse for Basic.

The proposed syntax is:  

inc = Function(y) y + 1

Which creates an anonymous single-parameter function that returns its parameter incremented by 1. This really doesn’t feel like VB, as a) It’s not line-oriented, and b) it implicitly returns y+1.

Even though it would prevent some common lambda use-cases, I’d prefer VB to only allow lambda expressions as variable initialization, and requiring multiple lines.

inc = Function(y) 
        Return y + 1 
      End Function 

This is only a fairly minor extension to existing Function and Sub usages. The above would only be allowed with Option Strict and Explicit disabled. Otherwise you’d get the usual:

Dim inc As Function(ByVal y As Integer) As Integer 
             Return y + 1 
           End Function 
Must Intrinsic Functions Be Keywords?

Several VB features involve mapping syntax that looks like a function call to CLR features. For example, Convert(x) becomes an appropriate ILAsm conversion function for the target assignment. If none of these had to be reserved as keywords, then it would simplify the language quite a bit. Assuming all the intrinsic function are in a suitable namespace, the usual namespace disimbiguation rules would apply.

If these keywords can become intrinsic functions in a namespace, then more useful variations could be added such as explicit SafeConvert and UnsafeConvert functions that map to the various ILAsm type conversion features.

Support Unmanaged Code

I’d like to be able to use VB syntax to write lower level code. Instead of dropping in to C++, I’d like to forgo garbage collection, and other fancy features to write small efficient code without giving up the readability of VB. A separate smaller set of System namespace libraries could be provided to give me everything I need to write device drivers, protocol stacks, and programs that need absolutely minimal footprint.


In summary the above proposals would eliminate 88 of the roughly 200 existing keywords while only adding 12 new ones. It would also eliminate some overloaded uses of current keywords, and introduce several powerful new features from other languages. The cost of all this is reducted compatibility with existing programs, eliminating the ability to simply compile. If this isn’t desirable, then a new Basic-style languages could be introduced. I believe the advantages of a much simpler yet more powerful language are worth it for writing new programs, and possibly even porting existing ones.

Although the language would retain approximately 120 keywords after these changes, the remaining ones seemed to make for more readable code than alternatives from other languages. Many of the remaining words can only be used as part of compound word key words, as with “Each” which can only be used in a “For Each” statement.

New Keywords (13)

[], Declare, Null, IsA, Hides, Scoped, Volatile, ”’, UsesAttribute, Define, ‘_’, Overrideable, NotOverrideable

Removed Keywords (86)

{}, CBool, CChar, CDec, CDbl, CInt, CLng, CObj, CSByte, CShort, CSng, CStr, CUInt, CULng, CUShort, CDate, CType, DirectCast, AddHandler, RemoveHandler, AddressOf, Alias, Declare, Ansi, Unicode, Lib, Dim, Object, Byte, Char, String, Integer, Short, Double, Single, Long, UInteger, ULong, UShort, SByte, Decimal, Date, Call, Declare, Delegate, Erase, ReDim, Preserve, Error, Resume, GetType, GoTo, Let, GoSub, Wend, Namespace (Or Module), Next, Nothing, Option, Explicit, Strict, Compare, Text, Binary, On, Off, RaiseEvent, REM, Shadows, Stop, SyncLock, TryCast, TypeOf, Assembly, IsTrue, IsFalse, Mid, ‘:’, ‘_’, ‘%’, ‘@’, ‘!’, ‘$’, Set, Get

IDE Features

Another problem with the current VB is some very annoying or broken IDE functionality.

Case Fixing Broken

VB is supposed to update the case of symbols to match their declaration, but this is currently broken in several instances. For example, when I type “imports\n” at the top of the file, it should automatically change it to “Imports System.Data\n”.

A concerted effort should be made to fix this in the various places where it doesn’t currently work, and additionally a simple Ctrl-K, Ctrl-D should fix up the whole document.

Indentation is broken

If you type “if blah then\n” then VB will automatically indent to the proper position on the next line. However, if you move the cursor to a different line, and then go back, it will no longer be at the correct position. This wouldn’t be too bad if the Tab key would take you to the correct position, but it does not.

Improve syntax recognition

The VB IDE used to be better about recognizing syntax as I type. For example, if I were to type “for<space>each<space>” on a line, then the IDE would capitalize “For” as soon as I hit the first <space> key. Currently, the IDE only colorizes “for” which tells me that it does recognize the keyword, but it doesn’t fix capitalization until the whole line is entered. I do think that most syntax errors shouldn’t be highlighted and indentation shouldn’t be changed until the line is finished, but case-fixing, coloring, and other formatting changes should happen as soon as possible. This used to be one of the best things about working with VB.

Tab key shouldn’t indent

It should be possible to redefine the tab key to always indent the current line to the correct position, and NEVER to actually insert indentation. Basically it should be have the same as Emacs Tab, but without having to choose Emacs emulation.

Allow assigning macros to tab

In previous versions of VisualStudio I was easily able to implement my own EmacsTab using a macro, and I was able to bind this to the tab key. This will require cleaning up the Code Snippets feature to not be hard-coded to use the Tab key for moving between editable fields.

Macros Too Difficult

A macro should be able to programmatically duplicate anything I can do using the keyboard. I’ve tried repeatedly to write a macro that would duplicate the functionality of the Emacs tab key, but I haven’t been able to get what I want. This macro took me only a few minutes to figure out with Visual C++ 6. In general the macro API is just too difficult-to-use for the amount of time have to devote to customization. Maybe a simplified facade should be provided. 

More Assistance

VB should be more helpful by more often allowing me not to type long keywords such as NotInheritable. For example, it could let me type the shorter text “not”, and then automatically expand it to the real keyword based on the current context. In general the VB parser should provide more context-sensitive assistance as I type code. It should always provide immediate but non intrusive feedback that it understands what I’m typing.

Non-Intrusive Layout

Often when I’m editing code, the current VB will immediately make layout changes as I type. This can make it very confusing in practice, because the indentation could “jump around” causing me to lose track of what I was doing. In general this is an example of VB taking the viewpoint of the parser rather than providing the illusion that it’s reading my mind. If I want to surround some code with “If … Then … End If”, then it only upsets me when VB immediately matches my newly inserted If with a previously existing End If, and indents my code accordingly. It’s only a slight distraction that some previous If now has a squiggly red underline indicating that it no longer has a matching End If. The solution is to ensure that VB doesn’t “jump to conclusions” on incomplete information. If a block of code contains syntax errors, then it should not be formatted, and it probably shouldn’t even be shown as a syntax error until I do something (Ctrl-S, Ctrl-K D, etc.) to indicate that I think the code is now correct. Perhaps VB could use a squiggly beige underline to tell me that it knows the code is not yet correct, but is currently waiting to see what I’ll type next.


I’d like some more advanced control over how the code is formatted. In addition to indentation stlye and coloring that are currently available, I’d like control over how keywords are capitalized, the ability to disallow language features, and other controls.

No More Compiling

When working with Eclipse/Java there is no concept of Compiling per se. Instead, the syntax is highlighted as you type, and certain actions like saving files or running the program will cause the compilation to happen in the background. This seems very much in the spirit of VB, and seems almost there already.

MultiFile Assemblies

It would make unit testing much better if VB allowed you to easily create unit tests in the same assembly as the tested code, but in a separate project. This allows me to expose testing interfaces as Friends. The current workaround is to just include the tests in the same project as the tested code.

Intellisense shows invalid values

Often, after typing “xyx<dot><ctrl-space>” I’ll be given a dropdown list of irrelevant information. If VB doesn’t know the actual members of the xyz object then it shouldn’t provide a list at all.

Automatic Imports

One extremely nice feature of Eclipse/Java is that it can automatically figure out the imports. If I type in “Dim sw As StringWriter<ctrl-space>” then VB should prompt me with a list of namespaces that have StringWriter types. If there is only one possible choice then it should not even prompt. Additionally it should insert the necessay Imports statement at the top of the file.

A corresponding feature from Eclipse/Java is the Ctrl-Shift-O keystroke which optimizes Imports. This automatically removes Imports that are no longer needed, and attempts to add any that are necessary. VB would require a new syntax for only importing selected types from a namespace.

Code Snippets

Several things about this feature really annoy me. Foremost is that the replacment fields stay active till the file is closed. Maybe it wouldn’t bother me as much if it was formatted differently, such as a solid underline that only highlighted when the field was the active one. The ugly green color is enough to prevent me from using this feature. The workaround I’ve decided on is to make the background color white. This makes the code snippet fields invisible unless the cursor is inside the field. Still, I’d like to be able to hit Enter (or maybe Ctrl-Enter) and have the fields finalized as if I’d closed and reopened the file.

Eliminate My

I’ve never liked the My feature very much. It seems like it could be replaced with the ability to assign duplicate Imports aliases. This would also allow me to pick a different name than “My”, and better control exactly what is included. For example, I might do the following:

Imports Foo As System.Text.RegularExpressions 
Imports Foo As Microsoft.VisualBasic.Devices 
Imports Foo As Microsoft.VisualBasic.FileIO 

This would combine all the listed namespaces into a single Foo namespace. Any ambiguities would have to be resolved explicitly as usual. It would also work with classes, allowing Shared methods to be called directly as usual.


Even though the list of things I would change about VB seems longer than my previous post about the things I like about VB, that shouldn’t give you the impression that I dislike the language. On the contrary I think it’s the best choice available on the .NET platform for most problems. C++/CLI provides more control, and the unique ability to comingle unmanaged and managed code. C# is similar to Java, more portable (Mono Linux), and has a few features that haven’t yet made it into VB. (yield, anonymous methods, unchecked, etc.) However, VB is the easiest to read and type, has the best editor, and is generally easier to work with for many problems.

This entry was posted in Programming Languages. Bookmark the permalink.

5 Responses to Things I Would Change in VB

  1. the wend of change says:

    uuuhhh what?

  2. David says:

    or you could just use C#

  3. Vina Rue says:

    Maybe 6 years since this was published, but I like VB.NET and I want to reply 🙂
    Most of what you say are reasonable. Some of your suggestions are interesting but they poses some issues. The following are the ones that I don’t agree with you at all.
    1) Typing “Declare” is annoying, typing “Dim” is much faster and easier.
    2) “Addressof” is necessary to avoid using the same keyword “Sub” for more than one purpose.
    3) “Goto” and “On Error” should be avoided in general, but there are situations that are necessary. It has been found some situations when C# programmers write lengthy code to do something similar to “On Error Resume Next”. In short, in some rare situations, you really want the compiler to just run what could be run without any bothering about errors.
    4) “Add Handler” is much clearer than “&=”
    5) I don’t agree with you about removing any feature. VB is always that you have much of options and dozens of constructs, and you can choose what you want. Removing these features will break the language flexibility. VB is designed to be convenient for the largest possible number of programmers. What you like is not what others like. All features should be kept, and you can choose what you want.
    The good points that you talked about are the ones that improve the existing language features, but not that remove them.
    Any way your article is nice, and I like it, that is why I feel pushed to comment even after 6 years!!!

    • justinmichel says:

      Wow. Thanks for taking the time to comment. I see your point on some of those things. Those were just a snapshot of my ever-fluctuating point of view on the topic.
      1) I still don’t love the keyword “Dim”, but I also wouldn’t want to substitute a much longer keyword. “Var” could work, but it’s not really much better than “Dim”, although it would probably be understandable given that C# programmers use it, and most VB.NET programmers have to know C# as a second language anyway. “Auto” might work too, as this would match what C++ chose for this purpose.
      2) I still think I’d prefer to use “Sub” instead of “AddressOf”. It seems like an even more natural option now that VB supports Lambdas.
      4) I think you’re right about AddHandler. I find using “&=” less readable. I still don’t see the advantage of the keyword vs making it a method on Event/Delegate though.
      3&5) Yeah, it’s tough to remove features. It might be nice to have some IDE flexibility to turn them into warnings/errors within the projects for a particular team though.

      I still really like VB too. I wish I were using it instead of Java on my current project. 😦

      • Vina Rue says:

        VB is always the best (Your article is really great). I always find VB smart and understands what the programmer wants. I think the whole story is about the designers. VB designers try to give the programmer what he wants. Other languages designers try to give the programmer the rules he should follow!!! Anyway, at the level of the semantics, I think Java is still more plausible than C#.
        Good Luck in your project 🙂

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s