Що ви думаєте про цей новий синтаксис if-then [закритий]

Я просто думав про те, що було б дійсно крутим, щоб я мав у своєму контролі if-elif-else.

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

Таким чином, в основному 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) встановіть змінну на вказаний статус успіху.

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

Він також логічно не читається. Якщо інше, якщо B, то C. Не означає комусь, що C буде виконано, якщо або A, або B оцінюють як істинне.

Цікаве, але мені здається (правда, дещо задане моїми способами) запрошення щодо проблем з читанністю, логікою та синтаксисом.

Редагувати: Ваш 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 або otherCondition) {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, але міг так само легко використовувати оператор перемикання з прапором:

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 (). Написання додаткового іншого, якщо цього не хочеться, вилучивши благ з того часу і додавши його до своїх ifs / elseifs. Тоді, коли ви чи інший програміст додасте ще одне твердження, ви можете очікувати виклику бла, але ні.

Або ви можете мати декілька ifs, написати благ і забути всі ifs, але потрібно один, який би щось порушив. Також є ймовірність, якщо вам потрібно, щоб вони дотримувались кожного, якщо ви поставите його під блок if. Можливо, встановіть bool в else (NoUpdate = true) і просто напишіть if (! NoUpdate) {} прямо під яким ясніше і може бути встановлено символом if

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

Я вважаю ваш синтаксис заплутаним, але я бачу деяку цінність у концепції. Концептуально, коли я розглядав це питання, те, що я вважав, що хочу, - це "неправе", яке в основному виконувало б справи у випадках, коли останні elseне стріляли . Дивлячись на це з цього кута, я б припустив, що можна досягти подібного результату через:

  робити
  {
    якщо (умова1)
      ... тільки для умови1
    інше, якщо (умова2)
      ... матеріал тільки для condition2
    ще
    {
      ... речі для жодної умови
      перерва;
    }
    ... речі для обох умов
  } while (0); // Точка продовження перерви

Іншим варіантом може бути:

  if ((умова1 && (action1,1)) ||
       (умова2 && (дія2,1)) ||
       (action_for_neither, 0))
    action_for_either;

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