boolean a = false, b = true;
if ( a && b ) { ... };
In most languages, b
will not get evaluated because a
is fals
Short-circuit, or minimal evaluation is just syntactic sugar for nested ifs. To assume it is inefficient, or causes stalls is a case of premature optimization. At this point, most compilers are intelligent enough to correctly interpret and optimize these statements. Using these statements can greatly reduce nesting, and therefore improve code readability, which should be your number one goal.
Languages supporting short-circuiting:
Ada, Eiffel, ALGOL 68, C1, C++, C#, Java, R, Erlang, Standard ML, Javascript, MATLAB, Lisp, Lua, Scheme, OCaml, Haskell, Pascal,Perl, Ruby, PHP, Python, Smalltalk, Visual Basic .NET
Taken from Short-circuit evaluation
VB.Net has a different syntax depending on whether or not you want it to short circuit or not. Because of legacy reasons, the default behaviour is to not short circuit. The syntax is as follows
Non Short Circuit
IF A And B THEN
...
END IF
Short Circuit
IF A AndAlso B THEN
...
END IF
You can use Or / OrElse if you want to short circuit an OR statement. Which is really nice in situations like the following
If MyObj IsNot Nothing AndAlso MyObj.Value < SomeValue Then
....
End If
Personally while I understand that short circuiting can speed things up, it's definitely not something that's obvious from just looking at the code. I could see an inexperienced developer getting confused by the behaviour. It even seems like something that could happen or not depending on compiler flags for level of optimization. I like how VB is verbose about which behaviour you actually want to accomplish.
I honestly wouldn't worry about it. Testing a boolean is really fast. Short-circuiting only gets interesting / useful when the second expression has side effects:
if ( ConfirmAction() && DestroyAllData() )
Reboot();
...or depends on the first test:
if ( myDodgyVar != null && myDodgyVar.IsActive() )
DoSomethingWith(myDodgyVar);
A useful short circuit I use is something like this:
if (a != null && a.equals(somevalue)) {
... do something.
}
This is, in my opinion very readable, and functions quite well. Generally, I try too avoid to much nesting because it leads to ugly code.
All my opinion though.
Most languages do short-circuit evaluation of boolean expressions. I have always heard it referred to as short-circuit evaluation.
The example in the question is a pretty simplistic example that doesn't really provide much of a performance benefit. The performance benefit comes when the expressions are complex to evaluate.
As an example of when this would be good imagine a game program that has something like:
if (someObject.isActive() && someOtherObject.isActive() && CollisionDetection.collides(someObject, someOtherObject) {
doSomething();
}
In this case the collision detection is far more expensive than the active checks. There would be a significant performance boost if there were lots of inactive objects in the system.