C#: should object variables be assigned to null?

In C#, is it necessary to assign an object variable to null if you have finished using it, even when it will go out of scope anyway?

No, and that could in fact be dangerous and bug-prone (consider the possibility that someone might try to use it later on, not realizing it had been set to null). Only set something to null if there's a logical reason to set it to null.

What matters more IMO is to call Dispose on objects that implement IDisposable.

Apart from that, assigning null to reference variables will just means that you are explicitly indicating end of scope - most of times, its just few instruction early (for example, local variables in method body) - with era of compiler/JIT optimizations, its quite possible that runtime would do the same, so you really don;t get anything out of it. In few cases, such as static variables etc (whose scope is application level), you should assign variable to null if you are done using it so that object will get garbage collected.

Should you turn off your car before pushing it to the lake?
No. It is a common mistake, but it doesn't make any difference. You aren't setting the object to null, just one reference to it - the object is still in memory, and must still be collected by the garbage collector.

Most of these responses have the right answer, but for the wrong reasons.

If it's a local variable, the variable will fall off the stack at the end of the method and therefore the object it was pointing to will have one less reference. If that variable was the only reference to the object, then the object is available for GC.

If you set the variable to null (and many who do were taught to do it at the end of the method) then you could actually wind up extending the time the object stays in memory because the CLR will believe that the object can't be collected until the end of the method because it sees a code reference to the object way down there. However, if you omit the setting of null the CLR can determine that no more calls for the object appear after a certain point in your code and, even though the method hasn't completed yet, the GC can collect the object.

Assigning to null is generally a bad idea:

1. Conceptually, it's just pointless.
2. With many variables, you could have enough extra assignments to null that you appreciably increase the size of the method. The longer the source code for something is, the more mental effort is taken to read it (even if much of it is just stuff that can be filtered out) and the easier it is to spot a bug. Make code more verbose than necessary only when doing so makes it more understandable.
3. It is possible that your null assignment won't be optimised away. In that case it's possible that the compiled code won't do the real deallocation until it actually reaches that null assignment, whereas in most cases once the variable is going to do nothing else other than fall out of scope (and sometimes even before) it can be deallocated. You can therefore have a very minor performance impact.

The only time I would assign something to null to "clear" a variable that will no longer be used, rather than because null is actually a value I explicitly want to assign, is in one of the two possible cases:

1. It is a member of a possibly long-lived object, will no longer be used by that object, and is of considerable size. Here assigning to null is an optimisation.
2. It is a member of a possibly long-lived object, will no longer be used by that object, and has therefore been disposed to release its resources. Here assigning to null is a matter of safety as it can be easier to find a case where one accidentally uses a null object than where one accidentally uses a disposed object.

Neither of these cases apply to local variables, only to members, and both are rare.

No. When it comes to local variables it makes no difference at all if you have a reference to the object or not, what matters is if the reference will be used or not.

Putting an extra null assignment in the code doesn't hurt performance much, and it doesn't affect memory management at all, but it will add unmotivated statements to the code that makes it less readable.

The garbage collector knows when the reference is used the last time in the code, so it can collect the object as soon as it's not needed any more.

Example:

{
  // Create an object
  StringBuilder b = new StringBuilder();
  b.Append("asdf");
  // Here is the last use of the object:
  string x = b.ToString();
  // From this point the object can be collected whenever the GC feels like it
  // If you assign a null reference to the variable here is irrelevant
  b = null;
}

For an object which has to implement IDisposable, as a practice I set all members to null in the implementation of IDisposable.

In the distant past I found this practice drastically improved the memory consumption and performance of a .NET Compact Framework application running on Windows Mobile. I think the .NET Compact Framework at the time probably had a very minimalistic implementation of the garbage collector compared to the main .NET Framework and the act of decoupling objects in the implementation of IDisposable helped the GC on the .NET Compact Framework do its thing.

An additional reason for this practice is after IDisposable has been executed on an object, it's actually undesirable for anything to attempt to use any of the members on a disposed object. Sure ideally you'd want an ObjectDisposedException out of an object which has been disposed when something attempts to access any of it's functions, but in place of that a NullReferenceException is better than no exception at all. You want to know about code messing with disposed objects as fooling around with unmanaged resources that have been released is something that can get an application into a lot of trouble.

NOTE: I'm definitely not advocating implementing IDisposable on an object for no other reason than to set members to null. I'm talking about when you need to implement IDisposable for other reasons, i.e. you have members which implement IDisposable or your object wraps unmanaged resources.

I'd just like to add that AFAIK this was only a valid pattern for one point release of Visual Basic, and even that was somewhat debatable. (IIRC it was only for DAO objects.)