как думаешь?
Ну такое.. прочесть конечно можно, но сложно.
Слишком много лишнего кода if (someTask?.IsCompleted ?? true) Так-то лучше
А лол, реально, сенкс, а то я автоматом всегда пишу == false или == true явно для более удобного чтения кода, в этом случае можно было и без этого обойтись, невнимательность
== falsе явно ещё вижу смысл, == true абсолютно бессмысленно)
Не знаю, лично мое мнение, if(method() == true) намного приятнее смотреть и понимать, чем if (method()), жаль что такое не практикуется. Просто в 1 варианте, мне кажется что можно понять суть логического выражения быстрее, чем во 2. Да, 2 варик меньше по коду, но не в том дело, повторяю, лично мое мнение, лично моя субъективная реальность.
если метод возвращает булевое значение, то обычно его называют начиная с Is или Has, например IsEnabled() или HasFlag(), поэтому когда пишешь if (IsEnabled()) то сразу все понятно и не надо ничего уточнять с == true
if (method() - думаю тут важно правильно назвать метод
Сделай екстеншен что-то типа public static T FallbackOn(this T? value, T fallback) => value ?? fallback; и тогда будет if(someTask?.IsCompleted.FallbackOn(true))
просто не надо называть это "method" Вот если if(IsSomething), то никакой ==true не надо
в случае, когда IsCompleted имеет значение отлично от true, код не валидный, например, вызвался CallbackToken, и IsCompleted кто-то поставил в false, идентифицируя таким таким образом fail state
лучше так if (someTask?.IsCompleted.HasValue && someTask?.IsCompleted.Value == true)
Нет, если не выполнялся await на этом task'е, то IsCompleted == false - штатная ситуация
ну тогда, получается, что стейт null никогда не выставляется?
Тогда уж if (someTask?.IsCompleted == true)
Обсуждают сегодня