C # короткий синтаксис проверки нуля - PullRequest
Новая
       3

C # короткий синтаксис проверки нуля

2 голосов
/ 25 февраля 2012

Недавно я много писал в Objective C, а также работал над несколькими проектами на C #.В этом процессе я обнаружил, что я скучаю по вещам в обоих направлениях.

В частности, когда я кодирую в C #, я обнаруживаю, что пропускаю синтаксис короткой нулевой проверки Objective C.

Почему вы предполагаете, что в C # вы не можете проверить объект на нулевое значение с помощью синтаксиса, такого как: 

if (maybeNullObject)  // works in Objective C, but not C#   :(
{
   ...
}

Я согласен, что if (maybeNullObject != null) является более подробным / понятным синтаксисом, но эточувствует себя не только утомительным постоянно писать в коде, но слишком многословно .Кроме того, я полагаю, что синтаксис if (maybeNullObject) обычно понимается большинством разработчиков (Javascript, Obj C и я предполагаю, что другие).

Я выбрасываю это как вопрос, предполагая, что, возможно, есть конкретная причина C #запрещает синтаксис if (maybeNullObject).Однако я думаю, что компилятор может легко преобразовать выражение объекта, такое как if (maybeNullObject) автоматически (или автомагически ), в if (maybeNullObject != null).

Отличная ссылка на этот вопрос: Какидея становится функцией языка C #? .

Редактировать

Синтаксис краткой проверки нуля, который я предлагаю, будет применяться только к объектам.Короткая нулевая проверка не будет применяться к примитивам и типам, таким как bool?.

Ответы [ 4 ]

9 голосов
/ 25 февраля 2012

Потому что if операторы в C # строгие.Они принимают только логические значения, ничего больше, и нет последующих уровней «правдивости» (т. Е. 0, ноль, что угодно. Они являются их собственным животным, и для них не существует неявного преобразования).

Компилятор может "легко преобразовать" почти любое выражение в логическое значение, но это может вызвать тонкие проблемы (поверьте мне ...), и было принято сознательное решение запретить эти неявные преобразования.

ИМО, это был хороший выбор.По сути, вы запрашиваете одноразовое неявное преобразование, когда компилятор предполагает, что, если выражение не возвращает логический результат, то программист должен захотеть выполнить проверку на нулевое значение.Помимо того, что он является очень узким признаком, он является чисто синтаксическим сахаром и дает мало или совсем не дает ощутимых преимуществ.Как говорит Эрик Липперт Вудл, каждая функция имеет стоимость ...

Вы запрашиваете функцию, которая добавляет ненужную сложность языку (да, она сложная, потому что тип может определять неявное преобразование в bool.Если это так, то какая проверка выполняется?) Только для того, чтобы вы не могли набирать != null время от времени.

РЕДАКТИРОВАТЬ:

Пример того, как определить неявное преобразование вbool для @Sam (слишком долго для комментариев). 

class Foo
{
    public int SomeVar;
    public Foo( int i )
    {
        SomeVar = i;
    }

    public static implicit operator bool( Foo f )
    {
        return f.SomeVar != 0;
    }
}

static void Main()
{
    var f = new Foo(1);         
    if( f )
    {
        Console.Write( "It worked!" );
    }
}
4 голосов
/ 25 февраля 2012

Одно потенциальное столкновение происходит с эталонным объектом, который определяет неявное преобразование в bool.

Для компилятора не существует разграничения между if(myObject) проверкой null или проверкой true.

1 голос
/ 25 февраля 2012

Вы можете написать метод расширения для System.Object, возможно, с именем IsNull ()?

Конечно, это все равно дополнительные 8 или 9 символов поверх кода, которые вам нужно написать длякласс расширения.Я думаю, что большинство людей довольны ясностью, которую дает явный нулевой тест.

1 голос
/ 25 февраля 2012

Намерение не оставить двусмысленности.Вы можете найти это утомительным, но эта короткая рука ответственна за множество ошибок за эти годы.C # справедливо имеет тип для логических значений, и было совестью принять решение не делать 0 означающим ложь, а любое другое значение - истинным.

...