Дополнительные Методы - IsNull и IsNotNull, хорошее или плохое использование?

Имеется прецедент, поскольку строковый класс имеет IsNullOrEmpty

Это вполне допустимо, но я не думаю, что это невероятно полезно. Поскольку методы расширения - это просто уловка компилятора, я с трудом могу назвать любое их использование "злоупотреблением", так как они в любом случае просто бесполезны. Я жалуюсь на методы расширения только тогда, когда они ухудшают читаемость.

Я не считаю это невероятно полезным, но это:

someString.IsNullOrBlank()    // Tests if it is empty after Trimming, too
someString.SafeTrim()         // Avoiding Exception if someString is null

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

Вместо этого я бы использовал что-то вроде:

static class Check {
    public static T NotNull(T instance) {
        ... assert logic
        return instance;
    }
}

Затем использовал бы это так:

Check.NotNull(x).SomeMethod();
y = Check.NotNull(x);

Лично мне гораздо понятнее, что происходит, чем быть умным и допустить следующее:

if( ((Object)null).IsNull() ) ...

Вы также вводите накладные расходы на вызов метода для чего-то, что является внутренней операцией CLR. JIT может встроить его, а может и нет. Конечно, это мелкая мелочь, но я согласен, что это не особенно полезно. Я делаю подобные вещи, когда есть значительное улучшение читабельности, или если мне нужно какое-то другое поведение, например «выбросить исключение ArgumentNullException и передать имя аргумента», что глупо делать встраиваемым снова и снова.

Это может иметь смысл, если вы, например, предполагаете, что вы можете захотеть генерировать исключение всякий раз, когда x равен нулю (просто сделайте это в методе расширения). Однако я лично предпочитаю в данном конкретном случае проверять явно (нулевой объект должен быть нулевым :-)).

Чтобы немного пояснить ответ Диланда:

Три класса реализуют класс FileResult :

System.Web.Mvc.FileResult
      System.Web.Mvc.FileContentResult
      System.Web.Mvc.FilePathResult
      System.Web.Mvc.FileStreamResult

Все они довольно понятны:

• Для пути к файлу загрузки, если файл существует на диске, используйте FilePathResult - это самый простой способ, позволяющий избежать использования потоков.
• Для массивов byte [] (аналогично Response.BinaryWrite) используйте FileContentResult .
• Для массивов byte [], в которые вы хотите загрузить файл (content-disposition: attachment), используйте FileStreamResult способом, аналогичным приведенному ниже, но с MemoryStream и с помощью GetBuffer () .
• Для потоков используйте FileStreamResult . Он называется FileStreamResult, но требует Stream , поэтому я

Я не совсем согласен с аргументацией "это может запутать".

В какой-то степени я понимаю, что имеется в виду, что нет причин выходить за рамки "общего понимания" - все понимают object != null.

Но в Visual Studio у нас есть замечательные инструменты, где вы можете просто навести курсор на метод, чтобы раскрыть некоторую дополнительную информацию.

Если мы скажем, что метод расширения был аннотирован с хорошим объяснением, то я чувствую, что аргумент путаницы рассыпается.

Методы .IsNotNull() и .IsNull() точно объясняют, что они такое. Я считаю их очень разумными и полезными.

По правде говоря, это вопрос "что вам нравится". Если вы чувствуете, что методы сделают его более читабельным в контексте вашего проекта, то соглашайтесь. Если же вы нарушаете условности в своем проекте, то я бы сказал наоборот.

У меня были те же мысли, что и у вас, по этому поводу, и я спрашивал нескольких очень опытных разработчиков у себя на работе. И никто из них не придумал веской причины (кроме той, что была упомянута здесь о -confusion-), которая бы объяснила, почему вы не должны этого делать.

Go for it :-)