Który jest bardziej odpowiedni sposób programowania

Question

Jeśli zmienna może przyjmować wartości n, powinniśmy sprawdzić poprawność wartości lub założyć, że jeśli wszystkie testy n-i ulegną awarii, będzie to n-ta wartość.

Na przykład jeśli mamy zmienną, która przechowuje płeć jako M lub F. użyj:

If gender = "M" 
    do male_processing 
else 
    do female_processing 
endif 

albo to:

If gender = "M" 
    do male_processing 
else 
    if gender = "F" 
    do female_processing 
    else 
    print "Something has gone wrong Gender has a value " Gender 
    endif 

endif 

Answer 1

Dla tego typu konstrukcji lubię używać instrukcji switch. Nie dlatego, że jest krótszy (nie jest), ale jest to bardziej czytelne (IMHO):

switch(gender) { 
    case "M": 
    doMaleSpecificStuff(); 
    break; 
    case "F": 
    doFemaleSpecificStuff(); 
    break; 
    default: 
    throw AnyError; 
} 

Answer 2

Krótko - to zależy od tego, jakiego typu jest zmienna. Jeśli jest to boolean lub wyliczenie jakiegoś rodzaju i nie ma innej wartości, jaką może mieć (w tym null) wystarczy zwykła klauzula else.

Można nawet dodać krótki komentarz tak:

if male: 
    do_male_stuff() 
else: #obviously female 
    do_female_stuff() 

Mając coś takiego po prostu wydaje się źle:

bool = SOME_BOOLEAN_VALUE 
if bool: 
    do1() 
elif not bool: 
    do2() 
else: 
    huh() #?!?! 

Konkluzja: mieć if/else/else if klauzuli dla każdego możliwy scenariusz, ale nie więcej niż ten i zachować czytelność.

Answer 3

Jeśli trzecia wartość, inna niż M lub F, jest możliwa, należy użyć drugiego formularza. Jeśli testowana zmienna jest typu, który może przyjąć tylko wartości M i F, powinieneś użyć pierwszego.

Answer 4

... lub w świecie OO można utworzyć klasę podstawową, na przykład Gender i rozszerzyć ją o klasy Male i Female. Zamiast przypisywania wartości "M" lub "F" do zmiennej, można przypisać instancję klasy Męskiej lub żeńskiej. Następnie po prostu wywołaj metodę określoną w klasie bazowej, na przykład doGenderSpecificStuff(). Nie ma tam potrzeby żadnych elfów.

Answer 5

W tym przykładzie, nie będę używać, jeśli w ogóle, to bym użyć przełącznik do drugiego przykładu

switch (gender) 
    case "M": 
     do male_processing 
     break 
    case "F": 
     do female_processing 
     break 
    default: 
     print "Something has gone wrong Gender has a value " Gender 
endswitch 

lub do pierwszego przykładu, to bym po prostu traktować jako wyjątki błędu używając ASSERT

assert (gender = "M" or gender = "F") 

Answer 6

Jeżeli wartości Gendre może być tylko „M” lub „F”, a następnie można użyć dochodzić to jasno:

Assert(gender = "M" OR gender = "F") 
If gender = "M" 
    do male_processing 
else 
    do female_processing 
endif 

Answer 7

Gdy wylicza sposoby obsługi różnych możliwych form typ danych, należy użyć wzoru dopasowania jeśli język obsługuje lub, jeśli nie, to switch (wzorzec dopasowania biedaka). Głównym powodem tego jest to, że jeśli typ danych zostanie rozszerzony o więcej potencjalnych formularzy, chcesz być ostrzeżony podczas kompilacji o niekompletnym dopasowaniu wzorca (lub instrukcji switch). W ten sposób możesz spać spokojnie wiedząc, że jeśli typatykę należy rozszerzyć, dowiesz się o tym wcześniej, niż później.

Zastosowanie domyślnego przypadku niestety cofa takie korzyści, więc w większości sytuacji powinieneś preferować wyliczanie wszystkich znanych możliwości jawnie.

Answer 8

Jeśli istnieje dane wejściowe użytkownika dla "F" lub "M", należy zagrozić trzem scenariuszom, tj. F, M i inne. Jeśli nie ma danych wprowadzonych przez użytkownika, możesz użyć dwóch i mieć wartość boolową, tj. isMale for if statement, więc byłoby znacznie bardziej czytelne.

Answer 9

Jeśli używasz typu wyliczeniowego, będzie on miał tylko te wartości, których się spodziewasz, i nie będziesz musiał zajmować się nieoczekiwanymi wartościami w IF, tylko przy przypisaniu.

Answer 10

Spróbuj sprawdzić wejścia i normalizuj tak szybko, jak to możliwe, możesz bezpiecznie użyć pierwszej opcji.

Jeśli twój interfejs użytkownika pozwala, aby dane wejściowe do tej zmiennej były dowolne (np. Pole tekstowe), to w twoim przykładzie możesz otrzymać "M", "Mężczyzna", "Mężczyzna", "Chłopiec" lub "Männlich" "możliwie uczciwe wkłady dla mężczyzn, zanim nawet uznają, że ktoś może zaproponować głupią odpowiedź. Sprawdzając (i normalizując) te wartości, zanim będziesz ich potrzebować, możesz zaoferować użytkownikowi bardziej elastyczne odpowiedzi.

Jeśli interfejs użytkownika ogranicza to do przycisku opcji, to jest znormalizowany jeszcze wcześniej.

Jeśli wartość jest pobierana z jakiegoś magazynu danych, to w zależności od aplikacji i znajomości integralności tego magazynu danych wartość sprawdzania ważności rekordu może być lub nie być dowolna. działając na wartości zawarte w.

Jeśli większość rekordów najprawdopodobniej się zgadza, a działania, które różne wartości wywołują, są tanie i odwracalne, skorzystam z drugiej opcji i wyrzucę wyjątek, jeśli wartość jest nieodpowiednia.