C#: should object variables be assigned to null?

Question

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?

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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;
}

Answer 5

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.)

Answer 6

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.