C #: ¿las variables de objeto deberían asignarse a nulo?

En C #, ¿es necesario asignar una variable de objeto a null si ha terminado de usarlo, incluso cuando salga de scope de todos modos?

No, y eso podría ser peligroso y propenso a errores (considere la posibilidad de que alguien intente usarlo más adelante, sin darse cuenta de que se ha establecido como nulo). Solo configure algo como nulo si hay una razón lógica para establecerlo como nulo.

Lo que importa más IMO es llamar a Dispose en los objetos que implementan IDisposable.

Aparte de eso, asignar valores nulos a las variables de referencia solo significa que está indicando explícitamente el fin del ámbito: la mayoría de las veces, solo unas pocas instrucciones anticipadas (por ejemplo, variables locales en el cuerpo del método), con la era de las optimizaciones del comstackdor / JIT, Es muy posible que el tiempo de ejecución haga lo mismo, por lo que realmente no obtienes nada. En algunos casos, como variables estáticas, etc. (cuyo scope es el nivel de aplicación), debe asignar la variable a nulo si ya no está utilizando, de modo que el objeto obtendrá basura recolectada.

¿Deberías apagar tu auto antes de empujarlo al lago?
No. Es un error común, pero no hace ninguna diferencia. No está configurando el objeto como nulo, solo una referencia al mismo: el objeto aún está en la memoria y aún debe ser recolectado por el recolector de elementos no utilizados.

La mayoría de estas respuestas tienen la respuesta correcta, pero por las razones equivocadas.

Si es una variable local, la variable caerá de la stack al final del método y, por lo tanto, el objeto al que apunta tendrá una referencia menos. Si esa variable era la única referencia al objeto, entonces el objeto está disponible para GC.

Si establece la variable en nulo (y muchos de los que lo hicieron se les enseñó a hacerlo al final del método), entonces podría terminar ampliando el tiempo que el objeto permanece en la memoria porque el CLR creerá que el objeto no puede ser recostackdo hasta el final del método porque ve una referencia de código al objeto muy abajo. Sin embargo, si omite la configuración de nulo, el CLR puede determinar que no aparecen más llamadas para el objeto después de un cierto punto en el código y, aunque el método aún no se haya completado, el GC puede recostackr el objeto.

Asignar a nulo generalmente es una mala idea:

  1. Conceptualmente, es inútil.
  2. Con muchas variables, puede tener suficientes asignaciones adicionales para anular que aumenta apreciablemente el tamaño del método. Cuanto más largo es el código fuente de algo, más esfuerzo mental se necesita para leerlo (incluso si gran parte de él es solo material que se puede filtrar) y más fácil es detectar un error. Haga que el código sea más detallado de lo necesario solo cuando hacerlo lo haga más comprensible.
  3. Es posible que su asignación nula no se optimice. En ese caso, es posible que el código comstackdo no realice la desasignación real hasta que llegue a esa asignación nula, mientras que en la mayoría de los casos una vez que la variable no hará nada más que caer fuera del scope (y algunas veces incluso antes) puede ser desasignado Por lo tanto, puede tener un impacto de rendimiento muy leve.

La única vez que asignaría algo a null para “borrar” una variable que ya no se usará, en lugar de que null es realmente un valor que explícitamente deseo asignar, se encuentra en uno de los dos casos posibles:

  1. Es un miembro de un objeto posiblemente de larga vida, ya no será utilizado por ese objeto, y es de un tamaño considerable. Aquí asignar a null es una optimización.
  2. Es un miembro de un objeto posiblemente de larga vida, ya no será utilizado por ese objeto y, por lo tanto, se ha dispuesto a liberar sus recursos. Aquí asignar a null es una cuestión de seguridad, ya que puede ser más fácil encontrar un caso en el que accidentalmente se usa un objeto nulo que cuando uno usa accidentalmente un objeto dispuesto.

Ninguno de estos casos se aplica a las variables locales, solo a los miembros, y ambos son raros.

No. Cuando se trata de variables locales, no hace ninguna diferencia si tiene una referencia al objeto o no, lo que importa es si la referencia se usará o no.

Poner una asignación nula adicional en el código no afecta demasiado el rendimiento, y no afecta en absoluto la administración de la memoria, pero agregará declaraciones no motivadas al código que lo hace menos legible.

El recolector de basura sabe cuándo se utiliza la referencia la última vez en el código, por lo que puede recostackr el objeto tan pronto como ya no se necesite.

Ejemplo:

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

Me gustaría agregar que AFAIK era solo un patrón válido para el lanzamiento de un punto de Visual Basic, e incluso eso era algo discutible. (IIRC era solo para objetos DAO)