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

Я поддерживаю некоторый код и нашел следующий шаблон много:

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

вместо этого:

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

есть ли какая-либо причина почему кто-нибудь сделал бы это? Кто-нибудь думает, что первое более читаемо или яснее? Есть ли какой-то старый C "gotcha", от которого это удержание?

13
c# coding-style conditional-operator readability

9 ответов

веская причина? Нет.

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

19

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

16

если вы не можете доверять:(row["Gender"].ToString() == "M") к продукту true или false правильно, тогда вы, вероятно, не можете действительно доверять:(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;

Мда...может, я вчера слишком поздно легла... :-)

10

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

по моему опыту, это часто происходит, когда условный оператор эволюционирует с течением времени и заканчивается с явным true или false, а не подпунктом.

4

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

Итак, с этой точки зрения это выглядит так:

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

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 делает короткую работу всех этих антишаблоны.

4

на 

if (somebool) return true;
else return false;

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

3

применение тернарного оператора ?: для выражения, которое может оценивать только 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).

2

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

1

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

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

1