Warunki Yody

Krótki post dedykujemy wszystkim fanom Gwiezdnych Wojen i Javy/JavaRush z okazji 40. rocznicy premiery V Epizodu Gwiezdnej Sagi! Czasami w Internecie można znaleźć wiele ciekawych rzeczy, a pewnego dnia natknąłem się na dość zabawną na pierwszy rzut oka praktykę programistyczną zwaną warunkami Yody . Krótko mówiąc, warunki Yody (także notacja Yody) to styl programowania, w którym dwie części znanego wyrażenia porównawczego w instrukcjach warunkowych są odwracane:

if (5 == a) {
    // do something
}

Stylu tego można używać w językach o składni podobnej do C, najczęściej w wyrażeniach z ifi while.

if (0 == variable) {
    // do something
}

while (false == endingCondition) {
    // do something
}

Po co przesuwać wyrażenie stałe na lewą stronę operatora porównania? Załóżmy hipotetyczną sytuację, w której po maratonie oglądania wszystkich dziewięciu sześciu części Sagi, bez snu, usiedliśmy, aby napisać kod do naszego ulubionego projektu i napisaliśmy co następuje:

void checkNumber(int a)
{
    if (a = 13) // Здесь-то и появляется так называемый unexpected behavior!
    {
        printf("Number is 13");
    }
}

W takim przypadku przy każdym uruchomieniu programu otrzymasz ciąg znaków Number is 13", niezależnie od argumentu przekazanego аdo metody checkNumber(int a). Nie tego się spodziewaliśmy! Błędy logiczne mogą zdarzać się dość często początkującym programistom (uwierz mi, WIEM). Ale na etapie kompilacji kod taki jak 13 = a spowoduje błąd, którego z pewnością nie przeoczymy, ponieważ wartość całkowita jest stała i dlatego nie może się zmienić (zamienić na „a”).

Korzystanie z warunków Yody ma zarówno zalety, jak i wady.

Jasna strona:

1. Zapobieganie przypisywaniu do zmiennej, gdy naszym celem jest porównanie.

2. Rozwiązywanie problemu niebezpiecznego „Zachowania zerowego” ( NullPointerException) // przykłady z Wikipedii

Bez Yody:

String myString = null;
if (myString.equals("foobar")) { /* ... */ }
// This causes a NullPointerException in Java

Z Yodą:

String myString = null;
if ( "foobar".equals(myString) ) { // Результат - Ложь
   /* не выполняется */
}

Ciemna strona:

1. Czytelność kodu dla osób, które będą na niego patrzeć, staje się bardziej złożona, co zwiększa obciążenie percepcji kodu.
2. Wąski zakres, używane jest tylko porównanie równości lub porównanie ze stałą, sprawdzanie wartości null.
3. Wiele kompilatorów już „widzi” tego rodzaju błędy i ostrzega z wyprzedzeniem o obecności potencjalnego błędu.

Alternatywą dla notacji Yody mogą być testy jednostkowe. W czasach Starej Republiki mówiono, że dobre testowanie gwarantuje, że kod będzie wolny od błędów i będzie robił tylko to, do czego został napisany. Jakie przydatne praktyki znasz? Podziel się swoją wiedzą w komentarzach! A także napisz swój ulubiony odcinek! I niech Moc będzie z Tobą!