Pregunta ¿Es la "mejor práctica de" ReferenceEquals (myObject, null) que "myObject == null"?


Tengo un compañero de trabajo que es fanático de escribir sus cheques nulos de la siguiente manera:

if (!ReferenceEquals(myObject, null))

Yo, por otro lado, encuentro esta sintaxis engorrosa para leer y prefiero:

if (myObject != null)

He encontrado algunos artículos y preguntas de desbordamiento de la pila sobre los méritos de ReferenceEquals con respecto a la sobrecarga del operador, pero fuera del escenario de sobrecarga del operador, ¿hay algún beneficio para ReferenceEquals vs ==?


32
2017-09-17 19:33


origen


Respuestas:


pero fuera del escenario de sobrecarga del operador, ¿hay algún beneficio para ReferenceEquals vs ==?

No, la única ventaja (y yo diría que no es una gran ventaja) para usar explícitamente Object.ReferenceEquals sería que nunca usará el operador sobrecargado igual. En el caso sin sobrecarga, el == Operador se define como "devuelve verdadero si sus dos operandos se refieren al mismo objeto" para todos los "tipos de referencia distintos de la cadena". Como tal, es equivalente (siempre que no esté sobrecargado).

Yo, personalmente, también estoy a favor de usar la segunda sintaxis, y la encuentro más fácil de mantener para la verificación nula. También diría que cualquier sobrecargado operator== también debe proporcionar una verificación adecuada contra null, y en el caso de que no lo hiciera por alguna razón (lo que sería extraño), es probable que exista una razón de ser específica detrás de esa decisión, lo que provocaría que desee usar la sobrecarga, no ReferenceEquals.


29
2017-09-17 19:36



Con c # 7, puede usar:

if ( !(myObject is null) )

Es equivalente a

if (!ReferenceEquals(myObject, null))

12
2017-11-11 00:44



Bueno, si alguien fuera a anular los operadores == o! = Podrían hacer que hagan lo que quieran. Incluso podría hacer que haga algo real como return true; o return false;. Además, si hay un operador sobrecargado, existe la posibilidad de que no funcione tan bien como ReferenceEquals (no está garantizado, y probablemente no es suficiente para importar, pero aún así).

Una vez dicho esto, dado que con cualquier implementación sensata de cualquier operador sobrecargado, es poco probable que esto sea un problema. Yo personalmente no uso ReferenceEquals a menos que tenga una razón convincente para no usar el == operador de ese tipo o en ese caso particular.


3
2017-09-17 19:38



En términos de controles nulos, los dos siempre deben devolver los mismos resultados. Si una referencia no nula alguna vez es igual a nula (incluso cuando se utiliza el patrón Objeto nulo), independientemente de si se utilizó ReferenceEquals o el operador ==, es una muy cosa mala. Entonces, en ese escenario, usaría == /! =.

Diría que, si el operador == estaba sobrecargado, usa ReferenceEquals podría ser ligeramente Más rápido. Lo primero que debería hacer un sobrecargado == es ver si las dos variables apuntan al mismo objeto, por lo que en el caso de un operador sobrecargado, usted termina con un marco extra en la pila de llamadas. El uso de ReferenceEquals también garantiza que ese es el solamente cheque realizado.

En general, también usaría == /! = En casi cualquier otro escenario. La idea completa es que el operador define "igualdad"; eso no siempre es referencial (de hecho, la mayoría de los objetos compuestos deben compararse estructuralmente para la igualdad, son iguales si sus miembros son iguales). El objeto, en teoría, sabe cuál es la mejor manera de compararse con otro objeto, por igualdad, orden relativo, etc. y así, en lugar de codificar una pieza de lógica muy específica y posiblemente incorrecta, debe usar la naturaleza orientada a objetos del lenguaje para deja que el objeto te diga si es igual a cualquier otra cosa o no.


1
2017-09-17 19:41



La etiqueta VB.NET probablemente no debería haber sido incluida en esta pregunta ya que no se menciona de otra manera, pero, para completar, Is es equivalente a Object.ReferenceEquals y así siempre se puede usar en lugar de esa llamada.


0
2017-09-18 08:24



ReferenceEquals podría ser un poco más rápido. Como se mencionó anteriormente, se asegura de que no se llame a ningún operador Equals sobrecargado. Además, ReferenceEquals asegura que solo se realiza una comparación en lugar de posiblemente 2, dependiendo de la implementación del operador Equals sobrecargado. Aunque es muy probable que el operador sobrecargado esté utilizando ReferenceEquals como la primera declaración.

Yo personalmente uso ReferenceEquals, pero solo en lugares donde realmente estoy retocando para exprimir los últimos ciclos de reloj (lugares que posiblemente se llaman millones de veces por segundo). O cuando no tengo control sobre el tipo, como en el caso de los genéricos. ... Pero nuevamente solo cuando el rendimiento es realmente crítico.


0
2018-02-12 15:54