Czy konieczne jest dodanie domyślnej skrzynki podczas korzystania ze skrzynek przełączników?

Podczas niedawnego przeglądu kodu poproszono mnie o umieszczenie defaultskrzynek we wszystkich plikach wszędzie tam, gdzie switchużywany jest blok, nawet jeśli nie ma nic do zrobienia default. Oznacza to, że muszę włożyć defaultsprawę i nic w niej nie pisać.

Czy to jest właściwe? W jakim celu miałoby to służyć?

Wydaje się, że istnieją trzy przypadki, w których defaultoświadczenie nie jest konieczne:

1. nie pozostały żadne inne przypadki, ponieważ istnieje ograniczony zestaw wartości, które wchodzą do switch case. Ale to może się zmieniać z czasem (umyślnie lub przypadkowo) i dobrze byłoby, default casegdyby coś się zmieniło _ możesz zalogować lub ostrzec użytkownika o złej wartości.

2. wiesz, jak i gdzie switch casezostanie użyty oraz jakie wartości go wprowadzą. Ponownie może się to zmienić i może być konieczne dodatkowe przetwarzanie.

3. inne przypadki nie wymagają specjalnego przetwarzania. Jeśli tak jest, myślę, że zostaniesz poproszony o dodanie default case, ponieważ jest to akceptowany styl kodowania i sprawia, że ​​kod jest bardziej czytelny.

Pierwsze dwa przypadki opierają się na założeniach. Tak więc (zakładając, że pracujesz w niezbyt małym zespole, ponieważ masz regularne przeglądy kodu), nie możesz sobie pozwolić na takie założenia. Nie wiesz, kto będzie pracował z twoim kodem lub nawoływał do funkcji / wywoływania metod w twoim kodzie. Podobnie może być konieczna praca z kodem innej osoby. Posiadanie tego samego stylu kodowania ułatwi radzenie sobie z czyimś kodem (w tym z Twoim).

Czy to jest właściwe? W jakim celu miałoby to służyć?

Często zdarza się, że standardy kodowania firm wymagają domyślnego przypadku dla wszystkich switchinstrukcji. Jednym z powodów jest to, że ułatwia czytelnikom znalezienie końca switch. Innym, prawdopodobnie lepszym powodem jest to, że sprawia, że ​​zastanawiasz się przez chwilę, co powinien zrobić Twój kod, gdy warunek nie spełnia twoich oczekiwań. Bez względu na powód wymagania, jeśli jest to standard firmy, należy go przestrzegać, chyba że istnieje uzasadniony powód, aby tego nie robić.

Jeśli uważasz, że switchobejmuje to przypadki dla każdego możliwego warunku, dobrze jest umieścić assertoświadczenie w przypadku domyślnym. W ten sposób, gdy ktoś zmieni kod i niechcący doda warunek, którego switchnie obejmuje Twój , uderzy asserti zda sobie sprawę, że musi zająć się tą częścią kodu.

Jeśli spełniasz switchtylko kilka możliwych warunków, ale dla innych nie musisz robić nic specjalnego, możesz pozostawić domyślną skrzynkę pustą. W takim przypadku dobrym pomysłem jest dodanie komentarza wskazującego, że przypadek domyślny jest celowo pusty, ponieważ warunki, które go dotyczą, nie wymagają żadnej pracy.

Jeśli „przełączysz” na czysty typ wyliczenia, niebezpiecznym jest mieć domyślną rezerwę. Gdy później dodasz wartości do typu wyliczenia, kompilator podświetli przełączniki z nowymi nieobjętymi wartościami. Jeśli masz tam domyślną klauzulę, kompilator pozostanie cichy i możesz go przegapić.

Pod wieloma względami to pytanie jest takie samo, jak często zadawane pytanie Czy potrzebuję elseklauzuli na końcu drabiny if/ else ifobejmującej każdą opcję .

Odpowiedź brzmi składniowo: nie, nie. Ale jest jednak ...

defaultPunkt może być nie do (co najmniej) dwóch powodów:

1. Jako program obsługi błędów - na pewno nigdy nie powinien się tu dostać! to roszczenie, które można złożyć, ale co jeśli tak będzie? Uszkodzenie danych lub, co gorsza, brak sprawdzania poprawności danych to drogi do niepowodzenia programu, jeśli nie zostaną właściwie uwięzione. W takim przypadku nie powinna to być pusta klauzula!
2. Projekt / pokrycie kodu - nawet w najprostszej formie schematu blokowego istnieją dwie drogi od instrukcji if i zawsze otherwiseod przypadku. Nie ma żadnego powodu, aby nie włączać ich do kodu źródłowego.

Moja filozofia jest zawsze bardzo prosta - oceń najgorszy możliwy scenariusz z dwóch opcji i wybierz najbezpieczniejszy. W przypadku pustego elselub defaultklauzuli najgorszych przypadków są opcje:

• Dołącz je: dodatkowe trzy lub cztery wiersze „nadmiarowego” kodu.
• Nie dołączaj ich: nieuczciwe dane lub nieoczekiwany stan nie są uwięzione, co może spowodować awarię programu.

Overdramatic? Może ... ale wtedy moje oprogramowanie może potencjalnie zabijać ludzi, jeśli pójdzie nie tak. Wolałbym nie ryzykować.

Tak na marginesie, że wytyczne MISRA-C {zobaczyć profil dla przynależności} polecić defaultklauzuli dla każdegoswitch

Java nie zmusza cię do posiadania „domyślnej” instrukcji, ale dobrą praktyką jest posiadanie jej przez cały czas, nawet jeśli kod nigdy nie zostanie osiągnięty (w tej chwili). Oto kilka powodów:

Dzięki nieosiągalnej klauzuli domyślnej pokazujesz czytelnikowi swojego kodu, że wziąłeś pod uwagę wartości i wiesz, co robisz. Zezwalasz także na przyszłe zmiany, powiedzmy na przykład: dodana jest nowa wartość wyliczeniowa, przełącznik nie powinien po cichu ignorować nowej wartości; zamiast tego możesz rzucić tam wyjątek lub zrobić coś innego.

Aby złapać nieoczekiwaną wartość (na wypadek, gdy nie włączasz wyliczenia), która jest przekazywana - może ona być na przykład większa lub mniejsza niż oczekiwana.

Do obsługi „domyślnych” akcji - gdzie przełączniki służą do specjalnego zachowania. Na przykład zmienną można zadeklarować poza przełącznikiem, ale nie można jej zainicjować, a każdy przypadek inicjuje ją na coś innego. Wartość domyślna w tym przypadku może zainicjować ją na wartość domyślną, aby kod natychmiast po przełączniku nie powodował błędu / nie zgłosił wyjątku.

Nawet jeśli zdecydujesz się nie umieszczać niczego w ustawieniach domyślnych (bez wyjątków, rejestrowania itp.), To nawet komentarz z informacją, że uważasz, że domyślnie nigdy się nie zdarzy, może pomóc w czytelności twojego kodu; ale sprowadza się to do osobistych preferencji.

Dodałbym również, że zależy to od filozofii używanego języka. Na przykład w Erlang, gdzie jest powszechne podejście do „pozwól mu się zawiesić”, nie zdefiniowałbyś domyślnego przypadku, ale pozwoliłbyś, aby twoja caseinstrukcja wygenerowała błąd, jeśli wystąpi sytuacja, która nie jest zaspokojona.

Zawsze powinieneś mieć domyślne, chyba że udowodniłeś i trwale objąłeś wszystkie sprawy. To nic nie kosztuje, a to ubezpieczenie od nieprzestrzegania instrukcji zmiany w ewoluującym programie.

Jeśli naprawdę jesteś pewien, że nie obchodzą Cię żadne inne przypadki, domyślnie: break; // nie przejmuj się, ale domyślna wartość domyślna powinna być podobna do domyślnej: wyrzuć nowy Błąd („nieoczekiwana wartość”);

Podobnie, nigdy nie powinieneś „odrzucać” nietrywialnej konstrukcji przypadku bez dodawania komentarza do efektu, który zamierzasz pominąć. Java pomyliła się na etapie projektowania.

Rozważać

enum Gender
{
       MALE ,
       FEMALE ;
}

i

void run ( Gender g )
{
      switch ( g )
      {
           case MALE :
                 // code related to males
                 break ;
           default :
                 assert Gender . FEMALE . equals ( g ) ;
                 // code related to females
                 break ;
      }
}

Argumentowałbym, że jest to lepsze niż posiadanie sprawy MALE, sprawy FEMALE i sprawy domyślnej, która zgłasza wyjątek.

Podczas fazy testowania komputer sprawdzi, czy g jest KOBIETĄ. Podczas produkcji kontrola zostanie pominięta. (Tak, mikrooptymalizacja!)

Co ważniejsze, utrzymasz swój cel 100% pokrycia kodu. Jeśli napisałeś przypadek domyślny, który zgłasza wyjątek, jak byś go kiedykolwiek przetestował?