この新しい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は、else条件を除いていずれかの条件が実行されたときに実行されます。これは便利だと思いますか？Pythonのtry-except-elseに似ています。

皆さんの中には、非常に予備的な実装を選んでいる人もいると思います。thenブロックは、同じようになりelse、ブロックtry-exceptのpythonでブロック。私がこれを提案する本当の理由は、このような状況のためです。

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の場合。AまたはBのいずれかがtrueと評価された場合、Cが実行されることを意味しません。

おもしろいですが、読みやすさ、ロジック、構文の問題への招待のように思えます（確かに私のやり方である程度設定されています）。

編集： あなたのif-elifは非常に簡単です-10のelifがあった場合はどうなりますか？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。Thenwith Doとfinal Elseをで置き換えOtherwiseます。

それはクールなアイデアのようです。しかし、私が想像する唯一の問題は、あなたがバグを起こしやすいということです。if / else ifを記述し、そのときblah（）を呼び出すのが好きです。それが何とかしたくない場合は余分な他のものを書き、そこから何とかを削除し、ifs / elseifsに追加します。その後、あなたや他のプログラマーが別のステートメントを追加すると、何とか呼ばれることを期待するかもしれませんが、呼び出さないでください。

あるいは、複数のifを持ち、何とか書き、すべてをifを忘れることができますが、1つは何かを壊すことになるこれを必要とします。また、ifブロックの下に配置する場合、すべてに従う必要がある場合もあります。else（NoUpdate = true）にブール値を設定し、if（！NoUpdate）{}を直接書く

私はそれがバグになりやすいと言っているだけではなく、私はアイデアが好きではないということではありません。私は言語でそれを見て気にしないだろうが、私の言語がそれをサポートしている場合、私はそれを使用する状況を想像することはできません。

あなたの構文はわかりにくいですが、このコンセプトには価値があります。概念的に、私が問題を検討したとき、私が望んでいるのは「基本的でelseはない」ことでした。その角度からそれを見て、私は1つを介して同様の結果を達成できることをお勧めします：

  行う
  {
    if（条件1）
      ... condition1のみのもの
    else if（条件2）
      ... condition2のみのもの
    そうしないと
    {
      ...どちらの条件にも当てはまらないもの
      ブレーク;
    }
    ...両方の条件に対応するもの
  } while（0）; //休憩の継続ポイント

場合によっては、別のオプションがあります。

  if（（condition1 &&（action1,1））||
       （condition2 &&（action2,1））||
       （action_for_neither、0））
    action_for_either;

見た目は少し厄介ですが、場合によっては、コードの複製や使用以外の目的のイベントシーケンスを表現する良い方法gotoがないかもしれません（誰かがここに挿入する漫画を除いて、それほど悪くないかもしれません）。