Использование true и false в качестве выражений в условной операции

Ответ 1

Допустимая причина? Нет.

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

Ответ 2

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

Ответ 3

Если вы не можете доверять: (row["Gender"].ToString() == "M") к правильному или ложному правилу продукта, то вы, вероятно, не можете действительно доверять: (row["Gender"].ToString() == "M") ? true : false;. Разумеется, вам, несомненно, нужно повторить его хотя бы несколько раз:

(row["Gender"].ToString() == "M") ? true : false ? true : false ? true : false;

Опять же, возможно, вы не можете доверять комбинации == и ?: сами по себе - чтобы быть уверенным действительно, вам, вероятно, потребуется как минимум немного избыточность:

if ((row["Gender"].ToString() == "M") ? true : false ? true : false ? true : false == true)
    isMale = true == true;
else
    isMale = false != false;

Хм... может, я слишком поздно пробыл прошлой ночью...: -)

Ответ 4

Я думаю, что это полностью избыточно.

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

Ответ 5

Я думаю, некоторым людям не удобно назначать что-либо другое, что true или false для логической переменной. Не знаю, почему это так, но я это наблюдал довольно много раз.

Итак, из этого аспекта это выглядит так:

установить сарказм на

bool isMale = (row["Gender"].ToString() == "M"); //BAAAAD

но

bool isMale = (row["Gender"].ToString() == "M") ? true : false; //BETTER

и

bool isMale;
if (row["Gender"].ToString() == "M") 
    isMale = true;
else 
    isMale = false;   // BEST!

установить сарказм

К счастью, Resharper делает короткую работу со всеми этими анти-шаблонами.

Ответ 6

if (somebool) return true;
else return false;

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

Ответ 7

Применение тернарного оператора?: выражение, которое может оценивать только true/false (x==y), просто избыточно (оно просто избыточно [оно избыточно]).

Вышеприведенное предложение может быть легче читать для тех, кто не очень хорошо понимает английский, поскольку они будут знать, что искать первым в словаре и, если говорить, из-за повторения. Однако для носителей английского языка предложение неудобно и, ну, лишнее.

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

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

var isMale = (row["Gender"].ToString() == "M"); // bool

или...

var isMale = (row["Gender"].ToString() == "M"); // true/false

... или еще лучше, явно укажите соответствующий тип для 'isMale' вместо того, чтобы полагаться на неявное типирование:

bool isMale = (row["Gender"].ToString() == "M");

Я также видел, как люди пессимизировали свой код таким образом (или используя if/else):

bool something = some_int ? true: false;

Нет необходимости делать это, и, хотя компилятор может оптимизировать это, по своей сути менее эффективно полагаться на механизмы ветвления над чем-то простым:

bool something = some_int != 0;

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

Этот вид кода просто смущает. Это похоже на:

switch (x)
{
    case 1: 
        y = 1;
        break;
    case 2:
        y = 2;
        break;
    case 3:
        y = 3;
        break;
    // etc. for all possible values of x
}

Вышеупомянутое, безусловно, будет считаться кодом uber-n00b большинством, но оно не является менее избыточным логически, чем x == y ? true: false или x ? true: false (в отличие от x != 0).

Ответ 8

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

Ответ 9

2-й способ уверен, имеет смысл, и мне кажется, что его легче читать.

Второй способ немного умнее. Я бы не пропустил мимо меня, чтобы сделать что-то вроде того, что ты находишь, если я собираю код в пятницу днем, и мой мозг уже ушел на выходные: -)