views:

165

answers:

5

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?

+7  A: 

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.

VinayC
@Vinay: are you saying that the garbage collector will look to see whether a variable is null to decide whether to garbage-collect? I thought it was just whether it was still alive/in-scope.
Craig Johnston
This powerpoint presentation http://download.microsoft.com/download/e/2/1/e216b4ce-1417-41af-863d-ec15f2d31b59/DEV490.ppt, slide 30 onwards, shows what the JIT/GC do together. It means the null assignment is particularly pointless.
Damien_The_Unbeliever
@Damien_The_Unbeliever - a good recource! thanks for that. @Craig, I was actually trying to say that its quite possible that GC will consider a object as garbage even if it is not *apparently* out of scope - all it cares is that if the ref is used or not. So its quite possible that object may get garbage collected even when instance method is running. See this excellent article: http://blogs.msdn.com/b/oldnewthing/archive/2010/08/10/10048149.aspx
VinayC
@Craig, continuing on - so its of no use of null assignment for say local variables that are going out of scope. But for static variables that has AppDomain level scope, the object will live till static variable hold the reference. So you may set it null explicitly if you no longer need that object.
VinayC
+7  A: 

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.

Daniel DiPaolo
This x a billion. You should only ever do *anything* if you *mean* to do it.
annakata
+5  A: 

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.

Kobi
+1  A: 

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;
}
Guffa
A: 

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.

Jon Hanna