If I want to narrow scope of a variable in C#, I can introduce additional braces - i.e.:
class Program
{
static void Main(string[] args)
{
myClass x = new myClass();
x.MyProperty = 1000;
Console.WriteLine("x = " + x.MyProperty);
{
myClass y = new myClass();
y.MyProperty = 2000;
Console.WriteLine("y = " + y.MyProperty);
}
myClass y2 = new myClass();
y2.MyProperty = 3000;
Console.WriteLine("y2 = " + y2.MyProperty);
}
class myClass
{
public int MyProperty { get; set; }
}
}
In the ide, I can no longer reference y outside of the scope introduced by the new braces. I would have thought that this would mean that the variable y would be available for garbage collection.
(it is interesting to note that when viewing the compiled code using reflector it appears that there is no difference with or without the additional braces)
Is there any way similar to this to narrow scope when using VB.net? Does this have any impact on when variables defined in the inner scope may be garbage collected?
Why not just create a few methods? A scope should be defined in a method. Once you exit the method you leave the scope - clean and easy. The way you are doing is very unorthodox - I would suggest you stick to convention and use methods if you are worried about scope creep (what you are describing).
Interestingly, the developerFusion c#-vb.net code converter converts
to
as a way of limiting the scope. I'm surprised it bothers bearing in mind paintballbob's answer
there doesn't seem to be a good way to create a new scope in vb, but you can make a loop that runs only once guaranteed and then declare your variable inside that loop.
MSDN had this to say about the lifetime of a variable:
src: http://msdn.microsoft.com/en-us/library/1t0wsc67.aspx
it seems that the variables are only subject to garbage collection once the procedure has finished, but even then the garbage collector will not run unless the heap is getting crowded. Most likely for small apps nothing ever gets garbage collected until the app is closed.
In C# at least, it doesn't make any difference to garbage collection when a debugger isn't attached - the GC is able to work out when a variable is last read, and a variable doesn't count as a GC root after that point. For example:
(In terms of terminology, the variable itself isn't collected, it's just that while it counts as a "root" to the garbage collector, it prevents the object it's referring to from being collected.)
When you've got a debugger attached, the GC is much more conservative, as you may want to examine a variable's value after its last "normal" read point.
The major benefit to reducing scoping is clarity, IMO. If a variable has a narrow scope, you can forget about it when you're not looking at that bit of code (assuming it's not captured by a delegate etc).
I don't know whether VB has any equivalent of a statement block for no reason other than scoping; the nearest equivalent may be a
With
statement... or aDo
...Loop While False
statement, neither of which is entirely satisfactory.