이 새로운 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조건은 else 조건을 제외한 조건이 실행될 때 실행됩니다. 이것이 유용하다고 생각합니까? 파이썬의 try-except-else와 비슷합니다.

나는 당신 중 일부가 매우 예비 구현을 nitpicking 생각합니다. then블록은 단지 같은 것이 elseA의 블록 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 인 경우 A 또는 B 인 경우 A 또는 B가 true로 평가되면 C가 실행될 것이라는 것을 다른 사람에게 암시하지 않습니다.

흥미롭지 만 가독성, 논리 및 구문 문제에 대한 초대는 나에게 (내 방식으로 다소 설정되어 있음) 보입니다.

편집 : if-elif는 매우 간단합니다-10 개의 elifs가 있다면 어떨까요? 20? 모든 조건이 사실이어야합니까? 그 기회는 무엇입니까?
if-elif는 매우 간단합니다. 10 개의 elif가 있다면 어떨까요? 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 ()"함수를 추가 할 수있었습니다. "else"보다는.

따라서 좀 더 일반적인 구문이 청구서를 채우는 매우 전문적인 구문 인 것 같습니다.

가능한 기능을 생각하면 +1하지만 (계속 유지하십시오!) 나는 그것을 구현하기 위해 투표하지 않을 것입니다.

나는 오늘 이와 같은 것을 사용하는 것을 신경 쓰지 않을 것입니다. 그러나 반복을 사용할 때까지 자주 사용할 것입니다.

불필요한 중첩이 없으면 코드가 더 좋아 보일 것입니다. 비록 선호 Else If합니다 elif. 나는 대체 것 Then으로 Do최종 Else와 Otherwise.

멋진 아이디어 인 것 같습니다. 그러나 내가 생각하는 유일한 문제는 당신이 버그에 더 취약하다는 것입니다. if / else if를 작성하고 그때 blah ()를 호출하는 것과 같습니다. blah를 원하지 않는 경우 추가를 작성하여 blah를 제거한 다음 ifs / elseif에 추가하십시오. 그런 다음 사용자 또는 다른 프로그래머가 다른 명령문을 추가하면 blah가 호출 될 것으로 예상되지만 그렇지 않을 수 있습니다.

또는 여러 ifs를 가질 수 있고, blah를 작성하고 모든 ifs를 잊어 버릴 수 있지만 하나는 무언가를 깨뜨릴 필요가 있습니다. if 블록 아래에두면 모든 것을 따라야 할 수도 있습니다. 아마도 (NoUpdate = true)에 bool을 설정하고 if (! NoUpdate) {}를 직접 작성하면 더 명확하고 if로 설정할 수 있습니다

나는 단지 버그가 더 발생하기 쉽다고 말하고 있습니다. 나는 그것을 언어로 보는 것이 마음에 들지 않지만 내 언어가 그것을 지원한다면 그것을 사용할 위치를 상상할 수 없다.

나는 당신의 구문이 혼란 스럽지만 개념에 약간의 가치가 있다고 생각합니다. 개념적으로, 내가이 문제를 고려했을 때, 내가 찾은 것은 "unelse"인데, 기본적으로 마지막 else이 실행되지 않은 경우에 실행 됩니다. 그 각도에서 보면 비슷한 결과를 얻을 수 있다고 제안합니다.

  하다
  {
    if (조건 1)
      ... condition1 전용
    그렇지 않으면 (조건 2)
      ... condition2 전용
    그밖에
    {
      ... 무조건에 대한 것
      단절;
    }
    ... 두 조건을위한 것
  } while (0); // 휴식을위한 연속 점

경우에 따라 다른 옵션은 다음과 같습니다.

  if ((condition1 && (action1,1)) ||
       (condition2 && (action2,1)) ||
       (action_for_neither, 0))
    action_for_either;

약간 불쾌하게 보이지만 경우에 따라 코드를 복제하거나 사용 goto하는 것 ( 원하는 사람이 여기에 삽입 할 수있는 만화를 제외하고는 나쁘지 않을 수도 있음) 이외의 원하는 이벤트 시퀀스를 표현하는 좋은 방법 이 없을 수 있습니다.