Czy instrukcje switch powinny zawsze zawierać domyślną klauzulę?

W jednej z moich pierwszych recenzji kodu (jakiś czas temu) powiedziano mi, że dobrą praktyką jest dołączanie domyślnej klauzuli do wszystkich instrukcji switch. Niedawno pamiętałem tę radę, ale nie pamiętam, jakie było uzasadnienie. Brzmi dla mnie dość dziwnie.

1. Czy istnieje uzasadniony powód, aby zawsze dołączać domyślne oświadczenie?

2. Czy ten język jest zależny? Nie pamiętam, jakiego języka używałem w tym czasie - może dotyczy to niektórych języków, a nie innych?

Obudowy przełączników powinny prawie zawsze mieć defaultobudowę.

Powody, dla których warto użyć default

1. Aby „złapać” nieoczekiwaną wartość

switch(type)
{
    case 1:
        //something
    case 2:
        //something else
    default:
        // unknown type! based on the language,
        // there should probably be some error-handling
        // here, maybe an exception
}

2. Aby obsłużyć „domyślne” akcje, w których przypadki dotyczą zachowania specjalnego.

Widać to DUŻO w programach sterowanych przez menu i skryptach powłoki bash. Możesz to również zobaczyć, gdy zmienna jest zadeklarowana poza przypadkiem przełączania, ale nie jest inicjowana, a każda sprawa inicjuje ją na coś innego. Tutaj domyślna również musi ją zainicjować, aby kod linii, który uzyskuje dostęp do zmiennej, nie powodował błędu.

3. Aby pokazać osobie czytającej Twój kod, że opisałeś tę sprawę.

variable = (variable == "value") ? 1 : 2;
switch(variable)
{
    case 1:
        // something
    case 2:
        // something else
    default:
        // will NOT execute because of the line preceding the switch.
}

To był zbyt uproszczony przykład, ale chodzi o to, że ktoś czytający kod nie powinien się zastanawiać, dlaczego variablenie może być czymś innym niż 1 lub 2.

Jedynym przypadkiem, o którym mogę NIE myśleć, defaultjest sytuacja, w której przełącznik sprawdza coś, co jest dość oczywiste, że każdą inną alternatywę można z radością zignorować

switch(keystroke)
{
    case 'w':
        // move up
    case 'a':
        // move left
    case 's':
        // move down
    case 'd':
        // move right
    // no default really required here
}

Nie.

Co się stanie, jeśli nie ma domyślnej akcji, kontekst ma znaczenie. Co zrobić, jeśli zależy Ci tylko na kilku wartościach?

Weź przykład czytania klawiszy w grze

switch(a)
{
   case 'w':
     // Move Up
     break;
   case 's':
     // Move Down
     break;
   case 'a':
     // Move Left
     break;
   case 'd':
     // Move Right
     break;
}

Dodawanie:

default: // Do nothing

To tylko strata czasu i bez żadnego powodu zwiększa złożoność kodu.

NIE posiadanie domyślnego przypadku może w rzeczywistości być korzystne w niektórych sytuacjach.

Jeśli twoje przypadki przełączania są wartościami wyliczanymi, nie mając domyślnego przypadku, możesz otrzymać ostrzeżenie kompilatora, jeśli brakuje jakichkolwiek spraw. W ten sposób, jeśli nowe wartości wyliczeniowe zostaną dodane w przyszłości i zapomnisz dodać przypadki dla tych wartości w przełączniku, możesz dowiedzieć się o problemie w czasie kompilacji. Nadal powinieneś upewnić się, że kod podejmie odpowiednie działanie dla nieobsługiwanych wartości, na wypadek gdyby do typu wyliczenia została użyta niepoprawna wartość. Może to najlepiej sprawdzać się w prostych przypadkach, w których można powrócić w przypadku wyliczenia, a nie zepsuć.

enum SomeEnum
{
    ENUM_1,
    ENUM_2,
    // More ENUM values may be added in future
};

int foo(SomeEnum value)
{
    switch (value)
    {
    case ENUM_1:
        return 1;
    case ENUM_2:
        return 2;
    }
    // handle invalid values here
    return 0;
 }

Zawsze używałbym domyślnej klauzuli, bez względu na to, w jakim języku pracujesz.

Sprawy mogą się nie udać. Wartości nie będą zgodne z oczekiwaniami i tak dalej.

Brak chęci dołączenia domyślnej klauzuli oznacza, że ​​masz pewność, że znasz zestaw możliwych wartości. Jeśli uważasz, że znasz zestaw możliwych wartości, to jeśli wartość jest poza tym zestawem możliwych wartości, powinieneś zostać o tym poinformowany - z pewnością jest to błąd.

Dlatego powinieneś zawsze używać domyślnej klauzuli i zgłaszać błąd, na przykład w Javie:

switch (myVar) {
   case 1: ......; break;
   case 2: ......; break;
   default: throw new RuntimeException("unreachable");
}

Nie ma powodu, aby podawać więcej informacji niż tylko ciąg „nieosiągalny”; jeśli tak się stanie, będziesz musiał spojrzeć na źródło i wartości zmiennych itp., a wyjątek stacktrace będzie zawierał ten numer wiersza, więc nie musisz marnować czasu na pisanie większej ilości tekstu w komunikacie o wyjątku.

W mojej firmie piszemy oprogramowanie dla rynku awioniki i obrony i zawsze dołączamy domyślną instrukcję, ponieważ WSZYSTKIE przypadki w instrukcji przełączania muszą być jawnie obsługiwane (nawet jeśli jest to tylko komentarz z napisem „Nie rób nic”). Nie możemy sobie pozwolić na to, że oprogramowanie po prostu źle się zachowuje lub po prostu ulega awarii na nieoczekiwanych (lub nawet naszym zdaniem niemożliwych) wartościach.

Można dyskutować, że domyślny przypadek nie zawsze jest konieczny, ale zawsze go wymagając, jest łatwo sprawdzany przez nasze analizatory kodu.

Czy instrukcja „switch” powinna zawsze zawierać klauzulę domyślną? Nie powinna ona zazwyczaj zawierają domyślne.

Dołączenie domyślnej klauzuli ma sens tylko wtedy, gdy jest coś do zrobienia, na przykład stwierdzenie błędu lub zachowanie domyślne. Zawarcie jednego „tylko dlatego, że” to program kultowy i nie ma żadnej wartości. Jest to odpowiednik „przełącznika”, który mówi, że wszystkie instrukcje „jeśli” powinny zawierać „inne”.

Oto trywialny przykład tego, gdzie nie ma to sensu:

void PrintSign(int i)
{
    switch (Math.Sign(i))
    {
    case 1:
        Console.Write("positive ");
        break;
    case -1:
        Console.Write("negative ");
        break;
    default: // useless
    }
    Console.Write("integer");
}

Jest to odpowiednik:

void PrintSign(int i)
{
    int sgn = Math.Sign(i);
    if (sgn == 1)
        Console.Write("positive ");
    else if (sgn == -1)
        Console.Write("negative ");
    else // also useless
    {
    }
    Console.Write("integer");
}

O ile wiem, odpowiedź brzmi „domyślnie” jest opcjonalna, mówiąc, że przełącznik musi zawsze zawierać wartość domyślną, to tak, jakby każde „if-elseif” zawierało „else”. Jeśli istnieje domyślna logika, powinna tam być instrukcja „default”, ale w przeciwnym razie kod mógłby kontynuować wykonywanie bez robienia czegokolwiek.

Posiadanie domyślnej klauzuli, gdy nie jest tak naprawdę potrzebne, to programowanie defensywne. Zazwyczaj prowadzi to do nadmiernie złożonego kodu z powodu zbyt dużej liczby kodów błędów. Ten kod obsługi i wykrywania błędów szkodzi czytelności kodu, utrudnia konserwację i ostatecznie prowadzi do większej liczby błędów niż rozwiązuje.

Uważam więc, że jeśli domyślna wartość nie zostanie osiągnięta - nie trzeba jej dodawać.

Pamiętaj, że „nie powinno zostać osiągnięte” oznacza, że ​​jeśli to osiągnęło, jest to błąd w oprogramowaniu - musisz przetestować wartości, które mogą zawierać niepożądane wartości ze względu na dane wprowadzone przez użytkownika itp.

Powiedziałbym, że zależy to od języka, ale w C, jeśli włączasz typ wyliczania i obsługujesz każdą możliwą wartość, prawdopodobnie lepiej nie uwzględniać domyślnego przypadku. W ten sposób, jeśli dodasz dodatkowy znacznik enum później i zapomnisz dodać go do przełącznika, kompetentny kompilator wyświetli ostrzeżenie o brakującej sprawie.

Jeśli wiesz, że instrukcja switch będzie miała zawsze ściśle określony zestaw etykiet lub wartości, po prostu zrób to, aby objąć podstawy, w ten sposób zawsze uzyskasz prawidłowy wynik. Po prostu ustaw domyślną wartość na etykiecie, która programowo / logicznie być najlepszym trenerem dla innych wartości.

switch(ResponseValue)
{
    default:
    case No:
        return false;
    case Yes;
        return true;
}

Przynajmniej nie jest to obowiązkowe w Javie. Według JLS mówi, że w jednym przypadku może występować jeden domyślny przypadek. Co oznacza, że ​​domyślna wielkość liter jest niedopuszczalna. Czasami zależy to również od kontekstu, w którym używasz instrukcji switch. Na przykład w Javie następujący blok przełączników nie wymaga domyślnej wielkości liter

private static void switch1(String name) {
    switch (name) {
    case "Monday":
        System.out.println("Monday");
        break;
    case "Tuesday":
        System.out.println("Tuesday");
        break;
    }
}

Jednak w poniższej metodzie, która spodziewa się zwrócić ciąg znaków, przydatna jest domyślna wielkość liter, aby uniknąć błędów kompilacji

    private static String switch2(String name) {
    switch (name) {
    case "Monday":
        System.out.println("Monday");
        return name;

    case "Tuesday":
        System.out.println("Tuesday");
        return name;

    default:
        return name;
    }
}

chociaż można uniknąć błędu kompilacji dla powyższej metody bez domyślnej wielkości liter, po prostu posiadając instrukcję return na końcu, ale podanie domyślnej wielkości liter sprawia, że ​​jest bardziej czytelna.

Tak mówią niektóre (nieaktualne) wytyczne, takie jak MISRA C :

Warunkiem końcowej klauzuli domyślnej jest programowanie defensywne. Klauzula ta podejmuje odpowiednie działania lub zawiera odpowiedni komentarz wyjaśniający, dlaczego nie podjęto żadnych działań.

Ta rada jest nieaktualna, ponieważ nie jest oparta na obecnie obowiązujących kryteriach. Rażące pominięcie jest tym, co powiedział Harlan Kassler:

Pozostawienie domyślnej wielkości liter pozwala kompilatorowi na opcjonalne ostrzeżenie lub błąd, gdy widzi nieobsługiwaną wielkość liter. Weryfikacja statyczna jest przecież lepsza niż jakakolwiek kontrola dynamiczna, a zatem nie jest godną poświęcenia, gdy potrzebujesz kontroli dynamicznej.

Jak wykazał również Harlan, funkcjonalny odpowiednik domyślnego przypadku można odtworzyć po przełączeniu. Co jest trywialne, gdy każdy przypadek jest wczesnym powrotem.

Typową potrzebą kontroli dynamicznej jest szeroko rozumiana obsługa danych wejściowych. Jeśli wartość pochodzi spoza kontroli programu, nie można jej ufać.

Tutaj także Misra zajmuje stanowisko ekstremalnego programowania obronnego, o ile tylko niepoprawna wartość jest fizycznie reprezentowalna, należy ją sprawdzić, niezależnie od tego, czy program jest poprawny. Ma to sens, jeśli oprogramowanie musi być jak najbardziej niezawodne w przypadku wystąpienia błędów sprzętowych. Ale jak powiedział Ophir Yoktan, większość oprogramowania lepiej nie „radzić sobie” z błędami. Ta ostatnia praktyka jest czasami nazywana programowaniem obraźliwym .

Powinieneś mieć ustawienie domyślne, aby przechwytywać nieoczekiwane wartości.

Jednak nie zgadzam się z Adrianem Smithem, że domyślny komunikat o błędzie powinien być czymś zupełnie bez znaczenia. Może istnieć nieobsługiwany przypadek, którego nie przewidziałeś (co jest w tym sensie), że użytkownik ostatecznie zobaczy, a wiadomość typu „nieosiągalny” jest całkowicie bezcelowa i nie pomaga nikomu w takiej sytuacji.

Przykładowo, ile razy miałeś zupełnie bezsensowny BSOD? Czy może śmiertelny wyjątek @ 0x352FBB3C32342?

Jeśli wartość przełącznika ( przełącznik (zmienna )) nie może osiągnąć wielkości domyślnej, wówczas wielkość domyślna nie jest wcale potrzebna. Nawet jeśli zachowamy domyślny przypadek, nie zostanie on w ogóle wykonany. To martwy kod.

Jest to opcjonalna „konwencja” kodowania. W zależności od zastosowania jest to, czy jest to potrzebne. Osobiście uważam, że jeśli nie jest to potrzebne, nie powinno tam być. Po co uwzględniać coś, z czego użytkownik nie skorzysta lub do którego nie dotrze?

Jeśli możliwości przypadków są ograniczone (tj. Wartość logiczna), klauzula domyślna jest zbędna !

Jeśli w switchinstrukcji nie ma domyślnego przypadku , zachowanie może być nieprzewidywalne, jeśli taki przypadek powstanie w pewnym momencie, czego nie można było przewidzieć na etapie opracowywania. Dobrą praktyką jest dołączanie defaultskrzynki.

switch ( x ){
  case 0 : { - - - -}
  case 1 : { - - - -}
}

/* What happens if case 2 arises and there is a pointer
* initialization to be made in the cases . In such a case ,
* we can end up with a NULL dereference */

Taka praktyka może spowodować błąd, taki jak zerowanie wartości NULL , wyciek pamięci, a także inne rodzaje poważnych błędów .

Na przykład zakładamy, że każdy warunek inicjuje wskaźnik. Ale jeśli defaultma się pojawić przypadek i jeśli nie zainicjujemy w tym przypadku, istnieje każda możliwość uzyskania wyjątku ze wskaźnikiem zerowym. Dlatego zaleca się stosowanie defaultinstrukcji case, nawet jeśli może być trywialna.

Domyślny przypadek może nie być konieczny w przełączniku używanym przez enum. gdy przełącznik zawierał całą wartość, domyślny przypadek nigdy się nie wykona. W takim przypadku nie jest to konieczne.

Zależy od tego, jak działa przełącznik w danym języku, jednak w większości języków, gdy żadna wielkość liter nie jest dopasowana, wykonanie przechodzi przez instrukcję przełącznika bez ostrzeżenia. Wyobraź sobie, że oczekiwałeś jakiegoś zestawu wartości i obsługiwałeś je w przełączniku, ale otrzymujesz inną wartość na wejściu. Nic się nie dzieje i nic nie wiesz. Jeśli złapałeś sprawę domyślnie, wiedziałbyś, że coś było nie tak.

Nie zgadzam się z najczęściej głosowaną odpowiedzią Vanwaril powyżej.

Każdy kod zwiększa złożoność. W tym celu należy również wykonać testy i dokumentację. Dlatego zawsze dobrze jest, jeśli możesz programować przy użyciu mniejszej ilości kodu. Uważam, że używam domyślnej klauzuli dla niewyczerpujących instrukcji przełączania, podczas gdy nie używam domyślnej klauzuli dla wyczerpujących instrukcji przełączania. Aby mieć pewność, że zrobiłem to dobrze, używam narzędzia do analizy kodu statycznego. Przejdźmy więc do szczegółów:

1. Niewyczerpujące instrukcje przełączania: zawsze powinny mieć wartość domyślną. Jak sama nazwa wskazuje, są to stwierdzenia, które nie obejmują wszystkich możliwych wartości. Może to również nie być możliwe, np. Instrukcja switch na wartości całkowitej lub na String. W tym miejscu chciałbym użyć przykładu Vanwarila (należy wspomnieć, że myślę, że użył tego przykładu, aby sformułować błędną sugestię. Używam go tutaj, aby stwierdzić odwrotnie -> Użyj domyślnej instrukcji):

   switch(keystroke)
   {
     case 'w':
       // move up
     case 'a':
       // move left
     case 's':
       // move down
     case 'd':
       // move right
     default:          
       // cover all other values of the non-exhaustive switch statement
   }
   

   Gracz może nacisnąć dowolny inny klawisz. Wtedy nie moglibyśmy nic zrobić (może to być pokazane w kodzie po prostu poprzez dodanie komentarza do domyślnej sprawy) lub powinno na przykład wydrukować coś na ekranie. Ten przypadek jest istotny, ponieważ może się zdarzyć.

2. Wyczerpujące instrukcje przełączania: te instrukcje przełączania obejmują wszystkie możliwe wartości, np. Instrukcje przełączania w wyliczeniu typów systemów ocen. Podczas opracowywania kodu za pierwszym razem łatwo jest uwzględnić wszystkie wartości. Ponieważ jednak jesteśmy ludźmi, istnieje niewielka szansa, aby o nich zapomnieć. Dodatkowo, jeśli dodasz wartość wyliczenia później, tak że wszystkie instrukcje przełączników muszą zostać dostosowane, aby stały się wyczerpujące, ponownie otwiera ścieżkę do błędu piekło. Prostym rozwiązaniem jest narzędzie do analizy kodu statycznego. Narzędzie powinno sprawdzić wszystkie instrukcje przełączników i sprawdzić, czy są wyczerpujące lub czy mają wartość domyślną. Oto przykład wyczerpującej instrukcji switch. Najpierw potrzebujemy wyliczenia:

   public enum GradeSystemType {System1To6, SystemAToD, System0To100}
   

   Następnie potrzebujemy zmiennej tego wyliczenia jak GradeSystemType type = ... . Wyczerpująca instrukcja przełącznika wyglądałaby wtedy następująco:

   switch(type)
   {
     case GradeSystemType.System1To6:
       // do something
     case GradeSystemType.SystemAToD:
       // do something
     case GradeSystemType.System0To100:
       // do something
   }
   

   Więc jeśli rozszerzymy GradeSystemType , na przykład, System1To3narzędzie do analizy kodu statycznego powinno wykryć, że nie ma domyślnej klauzuli, a instrukcja switch nie jest wyczerpująca, więc oszczędzamy.

Jeszcze jedna dodatkowa rzecz. Jeśli zawsze używamy defaultklauzuli, może się zdarzyć, że narzędzie do analizy kodu statycznego nie będzie w stanie wykryć wyczerpujących lub niewyczerpujących instrukcji przełączania, ponieważ zawsze wykrywa defaultklauzulę. Jest to bardzo złe, ponieważ nie zostaniemy poinformowani, jeśli rozszerzymy wyliczenie o inną wartość i zapomnimy dodać go do jednej instrukcji switch.

Czy instrukcje switch powinny zawsze zawierać domyślną klauzulę? Przypadki przełączania nie mogą istnieć bez domyślnego przypadku, w przypadku domyślnego przypadku przełącznika wyzwoli wartość przełączenia switch(x)w tym przypadku x, gdy nie będzie on zgodny z żadnymi innymi wartościami przypadków.

Uważam, że jest to dość specyficzne dla języka, aw przypadku C ++ drobna zaleta dla typu klasy enum . Co wydaje się bezpieczniejsze niż tradycyjne Cum. ALE

Jeśli spojrzysz na implementację std :: byte, to coś takiego:

enum class byte : unsigned char {} ;

Źródło: https://en.cppreference.com/w/cpp/language/enum

A także rozważ to:

W przeciwnym razie, jeśli T jest typem wyliczenia, który ma albo zakres, albo nie jest ustalony ze stałym typem bazowym, i jeśli lista stężeń inicjowanych ma tylko jeden inicjator, i jeśli konwersja z inicjalizatora na typ bazowy nie zawęża się, i jeśli inicjalizacja to inicjalizacja listy bezpośredniej, a następnie inicjowanie wyliczenia w wyniku konwersji inicjalizatora na typ bazowy.

(od C ++ 17)

Źródło: https://en.cppreference.com/w/cpp/language/list_initialization

Jest to przykład klasy wyliczającej reprezentującej wartości, które nie są zdefiniowanymi modułami wyliczającymi. Z tego powodu nie można całkowicie zaufać wyliczeniom. W zależności od aplikacji może to być ważne.

Jednak bardzo podoba mi się to, co @Harlan Kassler powiedział w swoim poście i sam zacznę stosować tę strategię w niektórych sytuacjach.

Tylko przykład niebezpiecznej klasy enum:

enum class Numbers : unsigned
{
    One = 1u,
    Two = 2u
};

int main()
{
    Numbers zero{ 0u };
    return 0;
}