Co sądzisz o nowej składni if-then [zamknięta]

Właśnie myślałem o czymś, co byłoby naprawdę fajne w moich kontrolach if-elif-else.

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

Zasadniczo a thenzostanie uruchomione, gdy którykolwiek z warunków zostanie uruchomiony Z WYJĄTKIEM warunku else. Czy uważasz, że to jest przydatne? Jest podobny do try-wyjątkiem-else Pythona.

Myślę, że niektórzy z was robią bardzo wstępne wdrożenie. thenBlok byłby podobnie jak elsebloku w try-exceptbloku w Pythonie. Prawdziwy powód, dla którego to sugeruję, dotyczy takich sytuacji.

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

thenBlok jest zawężona do pierwszego, czy podobnie jak elsejest. Tak więc zagnieżdżanie działa dobrze. A jeśli musisz uruchomić metodę przed instrukcjami if, to tak naprawdę nie ma to nic wspólnego z tym przypadkiem użycia.

Myślę, że to wygląda okropnie. Jeśli chcesz, aby kod działał po wielu różnych warunkach, albo (a) ponownie sprawdź te warunki lub (b) ustaw zmienną wskazującą status powodzenia.

Zasadniczo możesz już to zrobić za pomocą przełącznika / skrzynki, a przełącznik / obudowa zapewnia bardziej precyzyjną kontrolę nad tym, co proponujesz.

Nie odczytuje również poprawnie logicznie. Jeśli A, jeśli B, to C, to nie oznacza, że ​​C zostanie wykonane, jeśli A lub B zostaną ocenione jako prawdziwe.

Interesujące, ale wydaje mi się (co prawda nieco na mój sposób ustawione) zaproszenie do czytelności, logiki i problemów ze składnią.

Edycja: Twój if-elif jest bardzo prosty - a gdyby było 10 elifów? 20? Czy wszystkie warunki musiałyby być spełnione? Jakie są szanse na to?
Twój if-elif jest bardzo prosty - a gdyby było 10 elifów? 20? Czy to nie czyni tego dość nieczytelnym?

Ponadto można to łatwo osiągnąć, sprawdzoną metodologią:

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

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

Co się stanie, jeśli „stuff_that_applies_to_both” musi zdarzyć się przed poszczególnymi krokami? Twój kod nie obsługuje tego przypadku:

if (thisCondition or thatCondition)
{
  stuff_that_applies_to_both();

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

Wreszcie, ta składnia pozwala na większą elastyczność przy większej liczbie warunków: if (thisCondition or thatCondition or 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();
}

Korzystałem z if / else, ale równie łatwo mogłem użyć instrukcji switch z flagą:

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();

Zauważ, że tak naprawdę nie potrzebowałem flagi conditionApplies - mogłem dodać funkcję „stuff_that_applies_to_both ()” do obu warunków innych niż domyślne - właśnie to zrobiłem, aby wyglądało bardziej jak zdefiniowana powyżej składnia, aczkolwiek „wtedy” zamiast „else”.

Dlatego wydaje mi się, że jest to bardzo wyspecjalizowana składnia, w której bardziej ogólna składnia wypełnia rachunek i więcej.

+1 za myślenie o możliwej funkcji (rób to!), Ale nie głosowałbym na jej wdrożenie.

Dzisiaj nie miałbym nic przeciwko użyciu czegoś takiego. Ale, dla pewności, używałbym tego tak często, jak powtarzam do.

Kod przynajmniej wyglądałby lepiej bez zbędnego zagnieżdżania. Chociaż wolę Else Ifdo elif. Chciałbym wymienić Thenz Doa ostateczna Elsez Otherwise.

To wydaje się fajnym pomysłem. Jednak jedynym problemem, jaki sobie wyobrażam, jest to, że jesteś bardziej podatny na błędy. Jak napisanie if / else if i wywołanie blaha () w tym czasie. Napisanie dodatkowego, jeśli to nie chce bla, usunięcie bla z tego i dodanie go do ifs / elseifs. Następnie, gdy ty lub inny programista dodasz inną instrukcję, możesz oczekiwać, że zadzwoni bla, ale nie.

Lub możesz mieć kilka ifs, napisać bla i zapomnieć o wszystkich ifs, ale jeden wymaga tego, co by coś zepsuło. Są również szanse, jeśli będziesz ich przestrzegać, jeśli umieścisz ją pod blokiem if. Możliwe ustawienie bool w else (NoUpdate = true) i po prostu napisz bezpośrednio if (! NoUpdate) {}, pod którym jest jaśniejsze i może być ustawione przez if

Mówię tylko, że wydaje się bardziej podatny na błędy, nie że nie podoba mi się ten pomysł. Nie miałbym nic przeciwko widzeniu go w języku, ale nie wyobrażam sobie żadnego situtaion, w którym mógłbym go użyć, jeśli mój język to obsługuje.

Uważam twoją składnię za mylącą, ale widzę w niej pewną wartość. Koncepcyjnie, kiedy zastanawiałem się nad tym problemem, zauważyłem, że „unelse”, który w zasadzie działałby w przypadkach, gdy ostatni elsenie strzelał. Patrząc na to z tej perspektywy, sugerowałbym, że można osiągnąć podobny wynik poprzez:

  zrobić
  {
    if (warunek 1)
      ... rzeczy tylko dla warunku 1
    else if (warunek 2)
      ... rzeczy tylko dla warunku 2
    jeszcze
    {
      ... rzeczy na żaden warunek
      przerwa;
    }
    ... rzeczy dla obu warunków
  } while (0); // Punkt kontynuacji przerwy

Inną opcją może być w niektórych przypadkach:

  if ((warunek 1 i& (działanie1,1)) ||
       (warunek 2 i& (działanie 2,1)) ||
       (action_for_neither, 0))
    action_for_either;

Trochę nieprzyjemnie wyglądający, ale w niektórych przypadkach może nie być żadnego dobrego sposobu wyrażenia pożądanej sekwencji zdarzeń poza kopiowaniem kodu lub używaniem goto(co może nie być takie złe, z wyjątkiem kreskówki, którą ktoś mógłby tu wstawić).