VB.NET boolean operators and short-circuit evaluation
January 25, 2004
Having to pick up VB.NET for a Human Computer Interaction course this semester, I’ve been spending some time getting acquainted with the language through a couple of books. Every now and then I get somewhat bemused by how “different” VB syntax is - not that it’s a bad thing, pray. Syntax, as almost everyone agrees, is secondary to semantics.
Anyway, here’s a particularly bemusing bit of trivia you can use to taunt/jibe/provoke your VB.NET/VB programmer friends.
Did you know that VB.NET’s default boolean operators And and Or do not take advantage of short-circuit evaluation? Take for example this snippet of conditional code below:
If (x < 5) Or (x > 10) Then
Now, you’d expect your run-of-the-mill compiler/interpreter to optimize by short-circuiting the 2nd boolean expression, since the 1st expression is already true (and so whether the 2nd boolean expression is true or false doesn’t really matter). For some reason, probably one steeped in history, VB.NET, or rather the JIT compiler, doesn’t short-circuit. It happily goes ahead and evaluates the 2nd boolean expression.
This is logically ludicrous - short-circuit evaluation is how the logical human brain works when confronted with chained boolean conditionals in real life. If the university says I can only get a First Class Honours degree if my CAP is greater than 4.5 AND get a minimum of A- for my thesis, I won’t really fret about not getting an A- for my thesis (and subsequently missing out on a yummy First Class Honours) when my CAP can never hit 4.5.
Now to be fair, there is an alternative OrElse operator which does perform short-circuit evaluation. It is not fair though to expect such an unorthodox operator to be something your common on-the-street (read: non-VB) programmer will expect to exist (unless he reads a VB.NET book and bothers to flip to the introductory chapters).
Come to think of it, it could be an intended design issue. Evaluating the 2nd boolean expression could be always warranted when it produces a side effect. That must be the reason why Microsoft introduced the OrElse and AndAlso operators and leaving the standard And and Or operators as non-short-circuiting to prevent confusing converting VB programmers.
So this then is actually an issue with VB. Hence, we can conclude that they deserve to be taunted/jibed/provoked. Spare the VB.NET programmers. For now.
| Category: 
Now why won’t your teachers just let you use C#? ;)
In any case, I think Or is still around because that’s all that VB6 and earlier developers had. OrElse was just added in for VB.NET, and VB still has a lot of backward-compatible syntax that isn’t necessary with the .NET framework.
Posted by: Vinnie on January 27, 2004 2am