Это, безусловно, неэффективно в теории, как прямой тест if
, но это красная сельдь. Реальный вопрос: тебе не все равно?
У этого вопроса есть две стороны.
- Так что, если он медленнее? Если вы не выполняете это в цикле, связанном с процессором, который выполняется миллион раз, разница чисто теоретическая. Используйте все, что угодно, чтобы получить больше кода без ошибок, который приятно читать и поддерживать.
- Так что, если это уродливее? Вы собираетесь писать это много раз? Конечно, нет - если вы намереваетесь использовать много раз, поместите его в метод с хорошим именем и никогда больше не думайте об этом.
Что касается подхода LINQ, он немного короче и немного читабельнее, чем у вас:
if((new[] { null, " ", " ", "\n" }).Contains(x)) ...
Возможно, вы захотите написать другой метод расширения, который позволит вам вызывать его с обратным положением операнда, например,
if(x.In(new[] { null, " ", " ", "\n" })) ...
Вердикт: Я бы пошел с LINQ для более чем 3 или около того значений для проверки при условии, что нет другого более очевидного способа проверить эти значения (например, в этом случае IsNullOrWhiteSpace
очень близко), и нет никаких очевидных последствий для производительности. В противном случае if
проверено и верно.