April 13, 2005

Follow-Up To VB.NET Gotcha #1

I decided to dig into this a bit further after some feedback. This is from the Visual Basic .NET 2003 IDE:

i and j are out of scope

As is expected, i leaves scope as soon as the loop ends. j also leaves scope as soon as the loop ends. So what is the argument behind this behavior from the Visual Basic 2005 Language Enhancements chat? "This behaves the way that Visual Basic has always behaved."

I thought that there were two purposes behind the move from Visual Basic 6 to Visual Basic .NET. The first was fewer bugs through things like guaranteed zeroing of variables, improved object management, and guaranteed object disposal due to the garbage collector. The second was that there were going to be breaking changes in the language, so it was best to make all of them all at once.

I love Visual Basic because the language is essentially a common-sense language. You can look at a piece of code and know what it does. The code above looks like it makes a new j variable on each loop, but it doesn't.

As far as creating temporary variables inside of a loop, there are times when that makes sense. While performance may be increased by moving the allocation outside of the loop, there are also times where it is desirable to create variables at the beginning of the scope that they will be used in. That's why we got the For i As [Type] construct.

Fact is, I don't care what you do under the hood. If you allocate the memory ahead of time, that's fine...but the emitted code should function in a common-sense way. If a developer looks at the code and says that it appears like a new j is being created each loop, the end result should act like a new j is being created. That could mean you create and destroy the j, or it could mean you create j ahead of time, and just emit an MSIL instruction to zero it out at the point where the declaration is made.

You're already recognizing when it leaves scope...you may as well do the same for when it enters scope.


John Morales said...

Yeah, it certainly doesn't do what it looks like it should do.

To me (and this is just a personal preference), it looks goofy to Dimension a variable inside of a loop. Something about it just doesn't look right.

I'm sure that I've done it in loop structures that span 20 or 30 (or more) lines of code. In a loop like that, it seems that the developer's intention would be to have the variable declared at method scope, but just forgot to place the declaration properly.

This may be one of those cases where the language designers tried to outthink the developers... Maybe someone should ping Paul Vick on this.

Derick Bailey said...

it's annoying, at best, that VB.NET does not act like .NET in this instance. I'm pretty tired of all the VB6 people out there ruining VB.NET by demanding that it work exactly the same. When will they learn that we need to break the language in order to fix it?

I also did some research into this a while back... here's what I found.