Какой код более читаем?

Поскольку вы используете C #, я бы выбрал первую версию или использовал тернарный оператор ?: . Подобное использование && не является распространенной идиомой в C #, поэтому вас, скорее всего, неправильно поймут. В некоторых других языках (на ум приходит Ruby) шаблон && более популярен, и я бы сказал, что он уместен в этом контексте.

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

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

Так что, если Boo () никогда не должен вызываться, когда Foo () возвращает false, я бы выбрал версию №2, хотя бы как метод защитного программирования.

На мой взгляд, это сводится к намерению и ясности.

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

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

Таким образом, точка останова может быть установлена ​​перед вызовом Foo (), до вызов Bar () (и набор переменной), и когда для переменной установлено значение false - и, очевидно, те же самые точки останова также могут использоваться для перехвата случаев Foo () vs! Foo (), в зависимости от вопроса каждый имеет в виду.

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

Если, как вы указали, Bar () имеет побочные эффекты, я бы предпочел более явный способ. В противном случае некоторые люди могут не осознавать, что вы собираетесь воспользоваться преимуществом короткого замыкания.

Если Bar () является самодостаточным, я бы выбрал более лаконичный способ выражения кода.

Если бы первая версия выглядела так:

if (Foo() && Bar())
{
    SomeProperty = true;
}
else
{
    SomeProperty = false;
}

или так:

if (Foo())
{
    if (Bar())
       SomeProperty = true;
    else
       SomeProperty = false;
}
else
{
    SomeProperty = false;
}

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

Подождите. Эти утверждения даже не эквивалентны, не так ли? Я смотрел на них несколько раз, и они не оценивают одно и то же.

Сокращение для первой версии будет использовать тернарный оператор, а не оператор «и».

SomeProperty = foo() ? bar: false

Однако логическая ошибка в стороне. , Я согласен со всеми, что более короткая версия более читабельна.

Edit - Added

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

Отредактируйте снова - добавил еще:

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

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

Я бы выбрал второй вариант, но, вероятно, напишу его как в первый раз , а потом я бы его поменял :)

The first one, it's much more debuggable

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

Как вы думаете, как люди могут неверно истолковать вторую? Как вы думаете, они забудут этот && shortcircuits и будут беспокоиться о том, что произойдет, если второе условие будет вызвано, когда первое будет ложным? Если так, я бы не стал об этом беспокоиться - они были бы в равной степени сбиты с толку:

if (x != null && x.StartsWith("foo"))

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

В принципе, я бы выбрал вторую. С подходящим описательным именем переменной (и условиями) все должно быть в полном порядке.

Это зависит от того, что делают Foo и Bar.

Например, IsUserLoggedIn () && IsUserAdmin () определенно будет лучше в качестве && , но есть и другие комбинации (я могу '

SomeProperty = Foo() && Bar();

Это более читабельно. Я не понимаю, как кто-то мог откровенно выбрать другого. Если выражение && длиннее одной строки, разделите его на две строки ...

SomeProperty = 
   Foo() && Bar();

      -or-

SomeProperty = Foo() && 
               Bar();

Это почти не вредит читабельности и пониманию, ИМХО.

Мне нравится эта сокращенная запись, если ваш язык это позволяет:

SomeProperty = Foo() ? Bar() : false;

Я думаю, что лучший способ - использовать SomeProperty = Foo () && Bar () , потому что он намного короче. Я думаю, что любой нормальный .NET-программист должен знать, как работает оператор && -.

Когда я прочитал первый, он не был Сразу очевидно, что SomeProperty было логическим свойством, и Bar () не возвращал логическое значение до тех пор, пока вы не прочитаете часть оператора else.

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

Поскольку первый оператор требует от меня ссылки на часть else оператора, чтобы интерполировать, что и SomeProperty, и Bar () являются логическими по своей природе, я бы использовал вторую.

Во втором случае в одной строке кода сразу же становятся очевидными все следующие факты:

• SomeProperty является логическим.
• Foo () и Bar () возвращают значения, которые можно интерпретировать как логические.
• SomeProperty должно иметь значение false, если только Foo () и Bar () не интерпретируются как true.

Первый метод более читабелен, но позволяет получить больше строк кода, второй - более ЭФФЕКТИВНЫЙ, без сравнения, только одна строка! Я думаю, что вторая лучше

Ни то, ни другое. Я бы начал с переименования SomeProperty, Foo и Bar.

Я имею в виду, что вы должны структурировать свой код так, чтобы четко передать свои намерения. С разными функциями я могу использовать разные формы. Однако в нынешнем виде подойдет любая форма. Рассмотрим:

IsFather = IsParent() && IsMale();

и

if (FPUAvailable()) {
    SomeProperty = LengthyFPUOperation();
} else {
    SomeProperty = false;
}

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

Дело в том, что трудно ответить на этот вопрос с помощью SomeProperty, Foo () и Bar (). Есть несколько хороших общих ответов, защищающих && в обычных случаях, но я бы никогда полностью не исключил вторую форму.

I would say code is readable if it is readable to a person with no knowledge of the actual programming language so therefore code like

if(Foo() == true and Bar() == true)
then
    SomeProperty = true;
else
    SomeProperty = false;

is much more readable than

SomeProperty = Foo() && Bar();

If the programmer taking over the code after you isn't familiar with the latter syntax it will cost him 10 times the time it takes you to write those extra few characters.