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

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

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

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

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

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

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

Над

if (somebool) return true;
else return 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? истина: ложь или x? true: false (в отличие от x! = 0 ).

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

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

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

Думаю, некоторым людям неудобно присваивать что-либо другое, кроме 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!

отключили сарказм

К счастью, Решарпер быстро расправился со всеми этими антипаттернами.

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

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