Kwalifikacja: INF.03 - Tworzenie i administrowanie stronami i aplikacjami internetowymi oraz bazami danych

Warunek z zadania jest dobrym przykładem na to, jak JavaScript łączy sprawdzanie typu z logiką biznesową i gdzie często pojawiają się nieporozumienia. Kluczowe są tu dwie rzeczy: funkcja isNaN(x) oraz operator porównania x > 0. isNaN(x) zwraca true, gdy przekazana wartość „nie jest liczbą”, a więc !isNaN(x) oznacza, że x jest liczbą lub może zostać poprawnie zinterpretowane jako liczba. To automatycznie eliminuje typowe napisy, takie jak "abc" czy "test", bo one po konwersji dadzą NaN. Dlatego odpowiedź, że warunek jest prawdziwy dla napisu jako takiego, jest myląca – zwykły string tekstowy nie przejdzie tego filtra. Pusty napis też bywa źródłem zamieszania. W JavaScript isNaN("") zwraca false, bo pusty string jest konwertowany do 0, więc !isNaN("") jest prawdą. Jednak druga część warunku, czyli (x > 0), już nie przejdzie, bo 0 nie jest większe od zera. To pokazuje, że sam fakt „nie bycia NaN” nie wystarcza, potrzebny jest jeszcze sensowny zakres wartości. Częsty błąd polega na tym, że ktoś widzi isNaN i myśli tylko w kategoriach typu, a zapomina o tej części z porównaniem. Kolejny typowy skrót myślowy to przekonanie, że skoro jest sprawdzanie „czy to liczba”, to chodzi o dowolną wartość całkowitą. Tymczasem w warunku nie ma ani słowa o tym, że liczba musi być całkowita – nie ma tu żadnego sprawdzania modulo, parsowania przez parseInt, ani Math.floor. Warunek dopuszcza zarówno 1, jak i 1.5, 3.14 czy 0.0001, byle tylko były większe od zera i nie były NaN. W praktyce w JavaScript takie podejście jest zgodne z tym, jak działa typ number – reprezentuje zarówno liczby całkowite, jak i zmiennoprzecinkowe w jednym typie. Z mojego doświadczenia większość pomyłek przy takich zadaniach wynika z mieszania pojęć „napis, który wygląda jak liczba” z „napis jako tekst” oraz z ignorowania wpływu automatycznej konwersji typów. Dlatego przy projektowaniu walidacji wejścia warto zawsze myśleć o dwóch krokach: najpierw jawnie zamieniamy dane na liczbę, potem dopiero sprawdzamy zakres i warunki biznesowe, zamiast zakładać, że isNaN załatwi wszystko za nas.