Что вы думаете об этом новом синтаксисе if-then [закрыто]

Я просто думал о чем-то, что было бы действительно круто иметь в моем контроле if-elif-else.

if condition:
    stuff()
elif condition:
    otherstuff()
then:
    stuff_that_applies_to_both()
else:
    stuff_that_doesnt_aply_to_either()

Таким образом, в основном выполняется a then, когда выполняется любое из условий, КРОМЕ другого условия. Как вы думаете, это полезно? Это похоже на попытку-кроме-еще Python.

Я думаю, что некоторые из вас придираются к очень предварительной реализации. thenБлок будет так же , как elseблок в try-exceptблоке в питоне. Настоящая причина, по которой я предлагаю это, - в таких ситуациях.

m = {}
if condition == '1':
    m['condition'] = condition
elif condition2 == '3':
    m['condition2'] = condition2
elif condition3 == 'False':
    m['condition3'] = True
then:
    run_test_that_relies_on_one_of_the_conditions_being_true()

return m

thenБлок распространяется до первой , если так же , как elseесть. Так что вложение работает нормально. И если вам нужно запустить метод перед операторами if, это на самом деле не имеет ничего общего с этим вариантом использования.

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

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

Это также не читает правильно логически. Если A еще, если B, то C. Не подразумевает кого-то, что C будет выполняться, если либо A, либо B оценивают как true.

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

Редактировать: Ваш if-elif очень прост - что если бы было 10 elifs? 20? Все ли условия должны быть выполнены? Каковы шансы этого?
Ваш if-elif очень прост - что если бы было 10 elifs? 20? Разве это не сделает это довольно нечитаемым?

Кроме того, это может быть легко достигнуто проверенной методикой:

if (thisCondition or thatCondition)
{
  if (thisCondition)
     stuff();
  else
     otherstuff();

    stuff_that_applies_to_both();
}
else
{
    stuff_that_doesn't_aply_sic_to_either();
}

Что произойдет, если «stuff_that_applies_to_both» должно произойти перед отдельными шагами? Ваш код не обрабатывает этот случай:

if (thisCondition or thatCondition)
{
  stuff_that_applies_to_both();

  if (thisCondition)
     stuff();
  else
     otherstuff();
}
else
{
    stuff_that_doesn't_aply_sic_to_either();
}

Наконец, этот синтаксис обеспечивает большую гибкость при большем количестве условий: if (thisCondition или thatCondition или anotherCondition) {stuff_that_applies_to_all ();

  // Any combination of the three conditions using 
  // whichever logical syntax you'd like here
  if (thisCondition and anotherCondition)
     stuff();
  else if (thisCondition or thatCondition)
     stuff_number_2();
  else
     otherstuff();
}
else
{
    stuff_that_doesn't_aply_sic_to_either();
}

Я использовал if / else, но мог бы так же легко использовать оператор switch с флагом:

Boolean conditionApplies = true;

switch (someConditionToCheck)
{
    case thisCondition:
      stuff();
      break;

    case thatCondition:
        otherStuff();
        break;

    default:
        stuff_that_doesnt_aply_sic_to_either();
        conditionApplies = false;
        break;
}

if (conditionApplies)
    stuff_that_applies_to_both();

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

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

+1 за мысль о возможной функции (продолжайте делать это!), Но я бы не стал голосовать за ее реализацию.

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

Код, по крайней мере, выглядел бы лучше без лишних вложений. Хотя я предпочитаю , Else Ifчтобы elif. Я бы заменить Thenс Doи окончательным Elseс Otherwise.

Это похоже на классную идею. Однако единственная проблема, которую я представляю, это то, что вы более склонны к ошибкам. Например, написать if / else if и вызвать blah () в then. Написание дополнительного else, если это не нужно, бла, удаление бла с этого момента и добавление его в ваши ifs / elseifs. Затем, когда вы или другой программист добавите еще одно утверждение, вы можете ожидать, что будет вызван бла, но нет.

Или вы можете иметь несколько ifs, написать бла и забыть все if, но один требует этого, что может что-то сломать. Также есть вероятность, что вы будете следовать им, если будете помещать его под блок if. Возможно, установив bool в else (NoUpdate = true) и просто напишите if (! NoUpdate) {}, прямо под которым он более понятен и может быть установлен if

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

Я нахожу ваш синтаксис запутанным, но я вижу некоторую ценность в концепции. Концептуально, когда я рассматривал проблему, то, что я обнаружил, что мне нужно, это «unelse», который в основном будет выполнять вещи в тех случаях, когда последний elseне срабатывает. Глядя на это с этой точки зрения, я бы предположил, что можно достичь аналогичного результата с помощью:

  делать
  {
    если (условие1)
      ... материал только для condition1
    еще если (условие2)
      ... материал только для condition2
    еще
    {
      ... вещи ни для каких условий
      перемена;
    }
    ... вещи для обоих условий
  } while (0); // Продолжение точки перерыва

Другой вариант может быть в некоторых случаях:

  if ((условие1 && (действие1,1)) ||
       (условие2 && (действие2,1)) ||
       (Action_for_neither, 0))
    action_for_either;

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