Оформление сложных условий

Иногда проверки должны идти в строго заданном порядке и если одна будет ложной, то следующие проверять нельзя. Тогда подход с переменными становится бесполезным и приходится городить либо вложенные условия, либо сложные, а так – полезная практика.

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

bool mustRdraw = (frame.isChanged() || target.isChanged()) || experiment.isRunning();
bool isFullScreen = frame.getSize().equal(screen.getSize());
if (isFullScreen && mustRedraw) {
  // redraw
}

Допустим, что где-то вверху объявлена bool mustRedraw…
И… Бум!!!

Поступаю аналогично. Очень удобно построчно переносить код а также использовать условную компиляцию. Особенно такие конструкции разрастаются в sql (при этом true заменяется на 1=1). А для сложных случаев в комментариях описывается сначала таблица истинности, по которой, собственно, и составляется условие.

А true и false просто для того, чтобы не оставлять пустые открывающие скобки? Получается же и избыточность, и увеличение сложности. Стоит ли оно того?

Не совсем удобно. Любой мысль в коде должна быть или завершенной полностью, к примеру вызов метода с его аргументами на одной строке, либо явно намекать на то что «to be continue», т.е. ищи продолжение. Когда вы пишите && связывая под-условия, лучше всего это делать на одной строке, а продолжение мысли, т.е. написание след. под-условия на второй. Потому что когда Вы смотрите:

if ( file.Exists() &&

то Вы сразу понимаете, что мысль не завершена! Следовательно надо читать мысль(условие) далее!

И того Ваш кусок кода, при использовании моего предложения будет выглядеть так:

if ( true &&
condition1 &&
( false ||
condition_2_1 || condition_2_2 )
) {
// do something
}

Но я бы сделал так:

bool subCondition1 = true && condition1;
bool subCondition2 = false || (condition_2_1 || condition_2_2);
if (subCondition1 && subCondition2 ) {
// more code
}

P.S.: Сорри за то что не применяю тег код, он недоступен на хабре тем у кого карма ниже нуля.

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

libgcc/libgcc2.c — 1611:

if (! (- ((DWtype) 1 << FSIZE) < u
       && u < ((DWtype) 1 << FSIZE)))
  {
    if ((UDWtype) u & (REP_BIT - 1))
      {
        u &= ~ (REP_BIT - 1);
        u |= REP_BIT;
      }
  }	

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

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

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

Или еще какая-то ситуация, когда нужно написать сложное условие. Как поступим?

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

А вот у Мартина не помню упоминаний этой темы. Процитируете?

У Мартина Фаулера в «Рефакторинге» это называется «Замена вложенных условных операторов граничным оператором»