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

11

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.

Falmarri
źródło
jak zagnieżdżone może być?
aggietech
6
+1 za nieszablonowe myślenie, ale nie głosowałbym za jego wdrożeniem. Zobacz moją odpowiedź dlaczego poniżej.
Wonko the Sane
1
Więc „wtedy” działa jak finallyw Javie?
Alex Feinman,
1
Jestem thentrochę zagmatwany. Zazwyczaj thenzakłada się, że nastąpi po if. To znaczy, mówisz, if condition, then stuff()ale potem kontynuujthen stuff that applies to both
Matt Olenik
2
+1 za ciekawe ćwiczenie myślowe, ale zgadzam się z odpowiedziami złożonymi pod Bad Bad. To po prostu nie jest intuicyjne, i mogłem zobaczyć, że NAPRAWDĘ to zadziwia.
BlairHippo,

Odpowiedzi:

17

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.

Josh K.
źródło
2
Zgadzam się - bardzo trudno jest zrozumieć, co to znaczy bez wyjaśnienia, które podałeś.
tcrosley,
Dlaczego wymaga wyjaśnienia, jak coś działa zbyt wiele, aby się spodziewać?
Falmarri,
5
Ponieważ sprawia, że ​​kod jest trudniejszy do odczytania.
Antsan,
Nie jestem pewien, czy to sprawiedliwe. Każda konstrukcja w kodzie musi zostać wyjaśniona raz.
Mag
14

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.

Brian R. Bondy
źródło
2
Python nie ma instrukcji switch / case
Falmarri,
2
Nie sądzę, aby pytanie było sformułowane bezpośrednio w stosunku do Pythona tylko na odpowiedzi, ale jeśli taka była intencja, proszę również oznaczyć jako Python.
Brian R. Bondy
Cóż, nie jest bezpośrednio sformułowane w kierunku python. Przykładem był python. Ale jeśli twoją odpowiedzią na to, dlaczego nie jest to potrzebne, jest „istnieją instrukcje przełączania”, cóż, python ich nie ma.
Falmarri,
1
@Falmarri: W porządku, więc sądzę, że moją odpowiedzią byłoby, że Python lepiej obsługiwałby klasyczne instrukcje przełączników.
Brian R. Bondy
kod w pytaniu jest w Pythonie nie oznacza, że ​​pytanie dotyczy Pythona, ponieważ może to być również pseudokod. Jeśli chodzi tylko o Python, to powinien on zostać oznaczony jako taki
phuclv,
8

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.


1
+1 za „wypróbowaną i prawdziwie ustaloną metodologię” - jeśli istnieje rozsądne rozwiązanie problemu, zwykle najlepiej jest go użyć :)
bedwyr

what if there were 10 elifs? 20? Would all conditions need to be true?To nie jest możliwe. tylko 1 elif może być prawdziwy, ponieważ przestaje oceniać więcej.
Falmarri,

Mój błąd - czytam to jako „i” kiedy miałeś na myśli „lub”. Pozostaję jednak przy mojej odpowiedzi - zaktualizuję ją z tego, co wskazałeś.
Wonko the Sane

Czy naprawdę uważasz, że składnia, którą tu umieściłeś, jest jaśniejsza niż to, co zasugerowałem? Nie tylko sprawdzasz dwa razy warunki, ale brak zagnieżdżania jest zawsze lepszy niż zagnieżdżanie
Falmarri,

1
Podobnie jak twoje, chyba że twoje „wtedy” naprawdę odnosi się do wszystkich warunków, które, w miarę dodawania ich coraz więcej, stają się coraz mniej prawdopodobne. I osobiście, pochodząc z tła C / C ++ / C #, uważam, że zagnieżdżanie jest nieco mniej mylące niż podzielona składnia (tj. Robienie czegoś tutaj w „if” lub może „elsif”, a następnie robienie zeskakiwania i robienie czegoś jeszcze w „wtedy”. Osobiście uważam, że składnia jest bardziej czytelna, aby mieć wszystkie warunki razem. Może to nie być właściwe, ale jest to bardziej ugruntowana koncepcja w moim codziennym świecie.
Wonko the Sane

2

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.


Cóż, porozmawiaj z twórcami Pythona, a nie ze mną =]
Falmarri,

Och, myślałem, że projektujesz nowy język. Właśnie sugerowałem, żeby zmiany nazwy były bardziej precyzyjne, jeśli chcesz, zostaw elif, ale to ostatnie wydaje się inne niż zwykłe.
Peter Turner

Cóż, niekoniecznie jest to dla nowego języka, ale niekoniecznie dla Pythona. Ogólnie nowy pomysł na regułę składni. Można to zastosować w dowolnym języku ze stosunkowo niewielką liczbą efektów ubocznych.
Falmarri,

0

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.


źródło
Possibly setting a bool in else (NoUpdate=true) and just write a if(!NoUpdate) {} directly under which is clearer and can be set by an ifJest to DOKŁADNIE to, co ma temu zapobiec. To jest sedno oświadczenia elif. Elif też nie jest konieczny, można to sprawdzić za pomocą instrukcji if, ale komplikuje się.
Falmarri,
0

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ć).

supercat
źródło