Равно (item, null) или item == null

на этот вопрос нет простого ответа. любой, кто говорит всегда использовать тот или другой дает вам плохой совет, на мой взгляд.

на самом деле существует несколько различных методов, которые можно вызвать для сравнения экземпляров объектов. Учитывая два экземпляра объекта a и b, вы могли бы написать:

• Object.Equals(a,b)
• Object.ReferenceEquals(a,b)
• a.Equals(b)
• a == b

эти все могли делать разные вещи!

Object.Equals(a,b) будет (по умолчанию) выполнять сравнение ссылочного равенства для ссылочных типов и побитовое сравнение для типов значений. Из документации MSDN:

реализация Equals по умолчанию поддерживает равенство ссылки для ссылочные типы и побитовое равенство для типов значений. Равенство ссылок означает ссылки на объекты, которые сравниваемые относятся к одному и тому же объекту. Побитовый равенство означает объекты что сравниваются одинаковые двоичные представление.

обратите внимание, что производный тип может переопределить метод Equals в реализуйте равенство значений. Значение равенство означает сравниваемые объекты имеют одинаковое значение, но разные двоичное представление.

обратите внимание на последний абзац выше ... мы обсудим это позже.

Object.ReferenceEquals(a,b) выполняет сравнение только на равенство. Если переданные типы-это коробочные типы значений, результат всегда false.

a.Equals(b) вызывает метод виртуального экземпляра Object, который типа a может переопределить, чтобы сделать все, что он хочет. Вызов выполняется с помощью виртуальной отправки, поэтому код, который выполняется, зависит от типа выполнения a.

a == b вызывает статический перегруженный оператор типа * * времени компиляции a. Если осуществление этого оператор вызывает методы экземпляра на любом a или b, это также может зависеть от типов времени выполнения параметров. Поскольку отправка основана на типах в выражении, следующие могут дать разные результаты:

Frog aFrog = new Frog();
Frog bFrog = new Frog();
Animal aAnimal = aFrog;
Animal bAnimal = bFrog;
// not necessarily equal...
bool areEqualFrogs = aFrog == bFrog;
bool areEqualAnimals = aAnimal = bAnimal;

Итак, да, есть уязвимость для проверки нулей с помощью operator ==. на практике, большинство видов не перегрузка == - но нет никакой гарантии.

метод экземпляра Equals() это здесь не лучше. В то время как реализация по умолчанию выполняет проверку ссылочного/побитового равенства, тип может переопределить Equals() метод-член, в этом случае эта реализация будет вызвана. Пользовательская реализация может возвращать все, что захочет, даже при сравнении с null.

но как насчет статической версии Object.Equals() вы спрашиваете? Может ли это в конечном итоге запустить пользовательский код? Ну, оказывается, ответ-да. Реализация Object.Equals(a,b) расширяется что-то вроде:

((object)a == (object)b) || (a != null && b != null && a.Equals(b))

вы можете попробовать это для себя:

class Foo {
    public override bool Equals(object obj) { return true; }  }

var a = new Foo();
var b = new Foo();
Console.WriteLine( Object.Equals(a,b) );  // outputs "True!"

как следствие, возможно утверждение:Object.Equals(a,b) для запуска кода пользователя, когда ни один из типов в вызове null. Обратите внимание, что Object.Equals(a,b) не вызовите версию экземпляра Equals() когда любой из аргументов равен null.

короче говоря, тип поведения сравнения вы получаете может значительно отличаться, в зависимости от того, какой метод вы выберите позвонить. Один комментарий здесь, однако: Microsoft официально не документирует внутреннее поведение Object.Equals(a,b). Если вам нужен железный gaurantee сравнения ссылки на null без какого-либо другого кода, Вы хотите Object.ReferenceEquals():

Object.ReferenceEquals(item, null);

этот метод делает намерение чрезвычайно ясным - вы специально ожидаете, что результатом будет сравнение двух ссылок для ссылочного равенства. Преимущество здесь над использованием чего-то вроде Object.Equals(a,null), что это менее вероятно, что кто-то придет позже и скажет:

"Эй, это неудобно, давайте заменим его на:a.Equals(null) или a == null

, которые потенциально могут быть различными.

однако давайте привнесем немного прагматизма. до сих пор мы говорили о потенциале различных способов сравнения, чтобы дать разные результаты. Хотя это, безусловно, так, есть определенные типы, где безопасно писать a == null. Встроенный .Net классы как String и Nullable<T> имеют четко определенную семантику для сравнения. Кроме того, они sealed - предотвращение каких-либо изменений в их поведении по наследству. Следующее довольно распространено (и правильно):

string s = ...
if( s == null ) { ... }

нет необходимости (и некрасиво) писать:

if( ReferenceEquals(s,null) ) { ... }

в некоторых случаях, используя == безопасно и уместно.