> The most succinct way to put it is that the contents of a local variable are guaranteed to be alive at least as long as the current "point of execution" is inside the scope of the local variable.

AFAIK not really, unless you use GC.KeepAlive(). Some versions of .NET 2.0 even managed to collect "this" in the middle of a method if you didn't use any fields later, which led to a really ugly problem with handles, as your Dispose could release this.someIntPtr right between it being ldfld'ed and passed to some unmanaged method. Of course now we have SafeHandle which closes the handle itself, and with some pretty dark magic of CriticalFinalizerObject.

Hi Eric,

I'm really enjoying this "What's The Difference" series of posts, it's really cool that you're taking the time to dispel these common mis-conceptions.  It's also very cool to learn a new thing or two from reading your blog.  How many more posts will there be in this series?

Hope you're enjoying your holiday.  I wouldn't mind seeing some photographic evidence of these Beaver Sharks that we've heard so much about ;-)

>the current "point of execution" is inside the scope

Be careful not to mix up "lifetime" and "extent". ;)

This is why we refactored a large vb.net 1.x project to declare variables at the innermost scope instead at the head of the function.    This helped reduce bugs greatly and force the application to clean up resources as soon as possible instead of at the end of each method.  For some reason, the original offshore development team put in a large number of 500+ line functions via cut and paste code.

VS at some future version should allow refactoring to push varialbes to innermost scope.

"no two things are allowed to have the same name except for a set of methods that all differ in signature"

Alternatively, you could consider the method "name" to be a combination of the name and signature. For example, given:

void M()

void M(int)

void M(string)

void M(int, string)

you could assume that the method names look something like:

M

M@Int32

M@String

M@Int32@String

As I recall, the C++ compiler does something like this for overloading exported functions.

> force the application to clean up resources as soon as possible instead of at the end of each method

Neither scope nor declaration space of your locals have any effect on when GC will clean up resources. If you look at the IL generated from your code, you'll see that all local variables in a method are actually declared as "method scope" in IL. It doesn't really matter in the end, because the runtime is pretty smart at figuring out when a given local variable won't ever be used again, and thus should no longer be considered a root for GC purposes.

Pavel,

That's a consequence of the fact that scope is property of identifiers, and lifetime is not (it's a property of storage).  Storage can be identified by a different name in a different scope (with ref parameters), or even in the same scope (C++ references, or C# methods with multiple ref parameters with the same type).  At least one resource is reclaimed (although not by the GC) when execution leaves the defining (as opposed to aliasing) scope -- stack space.

Then in a GC environment such as .NET, instances of reference types have storage and lifetime completely distinct from the scope of handles to them.  But these handles are not identifiers for the instance's storage in the same way a ref parameter is, they can be reassigned to point to different storage.

Once new programmers learn the difference between storage and the identifier that names it, the distinction between scope and lifetime becomes straightforward.

@paul

> all local variables in a method are actually declared as "method scope" in IL.

>  It doesn't really matter in the end, because the runtime is pretty

> smart at figuring out when a given local variable won't ever be used

> again, and thus should no longer be considered a root for GC purposes.

Forgetting to cleanup allocated resources / variables is a symptom of poorly written code.   This covers obvious problems like not cleaning up open files, open sockets, ... to much harder ones like failing to properly deallocate a memory block returned by a thinly wrapped win32 api call.  

Developers that rely on the GC to cleanup introduce many expensive bugs into their code.

Moving variables to innermost scope greatly helps larger scale refactorings like extract method.  We used this many times to extract the inner body of an overly complicated method and make that extracted method static.  This resulted in much easier code to test, debug and verify it functions correctly.  

Essentially, it reduces to:

 "Reduce the context needed to understand a given line of code."

- Reduce nesting

- Reduce the need to know the state of an object before calling a method (i.e., use static methods when possible)

- Reduce the lines of code you need to read to get from the start of a method to any given line in that function

      - check for and return from errors before handling the non-error case (reduce nesting, ensure error handling is done for resource allocation)

      - don't declare variables at top of function, declare them inline where they are needed

      - precompute things that are used over and over (i.e., don't have 20 lines of object.array(25).methodz(1,2,3).propertyX called over and over just to access the properties)

- eliminate unused methods and properties (e.g., fold properties into the constructor if they are only used when constructing an object)

.

"Alternatively, you could consider the method "name" to be a combination of the name and signature. For example, given:"

It's rather complex because it, in your example includes only the name and return type of the signature for the purposes of treating them as one entity with multiple parts. Anything with a different return type in that situation is considered a clash within the declarative space.

However when you do it with methods in the base class as well

public class Bottom

{

public int Blah() {return 0;}

}

public class Bar : Bottom

{

   public double Blah() {return 0.0;}

}

Then this is considered acceptable (albeit with a compiler warning without new) as you are allowed to shadow, thus cover up one declarative space with another.

Of course the moment you make Bottom's Blah private this issue goes away so the *maximum* access level in the base class(es) alters the declarative space for sub classes but has no effect on the space *within* the class.

but wait. it gets worse :)

public interface IFoo

{

int Blah();

}

public class Bottom : IFoo

{

    int IFoo.Blah() {return 0;}

}

public class Bar : Bottom

{

   public double Blah() {return 0.0;}

}

suddenly the compiler warning goes away because we have pushed the declarative space into the interface and, despite Bar being usable as an IFoo and truly implementing it, it is only accessible from variables where you stop being able to treat it as a Bar, hence the spaces cannot clash. Good that the compiler is clever about this but you begin to see the complexity of it.

I'd hate to have to implement a compiler, though it's probably a source of combined maddening and marvellous all at once :)