Przerwij domyślną wielkość liter w przełączniku

breakCzęsto zastanawiam się nad tym, czy mogę to uwzględnić po ostatnim przypadku default.

switch (type) {
    case 'product':

        // Do behavior

        break;
    default:

        // Do default behavior

        break; // Is it considered to be needed?
}

breakmoim jedynym celem jest zatrzymanie uruchamiania kodu przez resztę switchskrzynki.

Czy zatem uważa się za bardziej logiczne, aby mieć breakostatnią ze względu na spójność lub pominąć ją ze względu na breakbrak zastosowania funkcjonalnego? Oba są moim zdaniem logiczne na różne sposoby.

Można to do pewnego stopnia porównać z zakończeniem .phppliku ?>. Nigdy nie kończę, ?>głównie ze względu na ryzyko generowania pustych miejsc, ale można argumentować, że logicznym rozwiązaniem byłoby zakończenie pliku.

breaknie jest technicznie potrzebny po ostatniej alternatywie (która, defaultniestety , wcale nie musi być : jest całkowicie legalna, a czasem nawet przydatna, aby umieścić defaultgałąź na pierwszym miejscu); to, czy kod wypadnie na końcu switchinstrukcji, czy breaksna końcu ostatniej gałęzi, ma ten sam wynik.

Jednak nadal kończę każdą gałąź, w tym ostatnią, instrukcją returnlub breakz trzech powodów:

1. Refaktowalność. Jeśli wszystkie gałęzie kończą się na breaklub return, możesz zmienić ich kolejność bez zmiany znaczenia. To sprawia, że ​​mniej prawdopodobne jest, aby taka zmiana kolejności wprowadziła regresję.
2. Spójność i najmniejsza niespodzianka. Spójność mówi, że twoje gałęzie powinny kończyć się konsekwentnie, chyba że faktycznie mają inne znaczenie. Zasada najmniejszej niespodzianki mówi, że podobne rzeczy powinny wyglądać podobnie. Zakończenie ostatniej gałęzi switchbloku dokładnie tak, jak poprzednie spełnia oba, co ułatwia czytanie i zrozumienie. Jeśli pominiesz wyraźne break, ostatnia gałąź będzie optycznie inna (co jest szczególnie ważne w przypadku szybkiego skanowania), a aby zobaczyć, że tak naprawdę nie jest inaczej, czytelnik musi zejść do drobiazgowego poziomu czytania poszczególnych instrukcji .
3. Chronić siebie. Jeśli przyzwyczaisz się kończyć wszystkie swoje switchgałęzie break, po pewnym czasie stanie się ono automatyczne i rzadziej przypadkowo zapomnisz, gdzie to ma znaczenie. Przygotowanie się do oczekiwania breakna końcu każdej gałęzi pomaga również w wykrywaniu brakujących breakinstrukcji, co doskonale nadaje się do debugowania i rozwiązywania problemów.

Biorąc pod uwagę niejednoznaczność, jaka istnieje wokół używania switch-casew większości języków, podczas korzystania z niego sugerowałbym, aby zawsze używać breakoświadczenia, z wyjątkiem przypadków, gdy jest to wyraźnie i z założenia niepożądane .

Częściowo dzieje się tak, ponieważ sprawia, że ​​każde casepołączenie wygląda tak samo, co moim zdaniem poprawiłoby czytelność. Ale oznacza to również, że jeśli ktoś (nawet ty) zdecyduje się wstawić casepo ostatnim na późniejszym etapie, nie musi zajmować się sprawdzaniem poprzedniego bloku, co może pomóc w zmniejszeniu błędów podczas dodawania nowego kodu.

breakPo ostatnim przypadku nie jest konieczne . Używam słowa „ ostatni ” (nie domyślny ), ponieważ nie jest to konieczne, domyślny przypadek to ostatni przypadek.

switch(x)
{
case 1:
//do stuff
break;

default:
//do default work
break;

case 3:
//do stuff

}

I wiemy, że break konieczne jest a pomiędzy dwoma kolejnymi cases. Czasami używam if(a!=0)w swoim kodzie dla większej czytelności, gdy inni odsyłają mój kod. Mogę wybrać użycie if(a), to byłby mój wybór