Pytanie 1
Który z warunków logicznych weryfikuje, czy zmienna całkowita x jest dodatnią liczbą składającą się z dwóch cyfr i jest podzielna przez 4?
A. (x > 9 && x < 100) && (x % 4 == 0)
B. (x > 9 && x < 100) || (x % 4 == 0)
C. (x > 0 && x < 100) || (x / 4 == 0)
D. (x > 9 || x < 100) && (x / 4 == 0)
Wydaje mi się, że często można się tu pomylić przez mylne rozumienie operatorów logicznych i arytmetycznych, szczególnie gdy chodzi o '&&' i '||'. Połączenie 'lub' zamiast 'i' (czyli operatora || zamiast &&) powoduje, że warunek przechodzi dla zbyt szerokiego zakresu liczb – np. sprawdzenie (x > 9 || x < 100) jest praktycznie zawsze prawdziwe dla większości wartości x, bo każda liczba większa od 9 lub mniejsza od 100 spełnia przynajmniej jeden z tych dwóch warunków. To nie ogranicza wyniku do liczb dwucyfrowych, tylko praktycznie do prawie wszystkich liczb całkowitych poza bardzo małym wyjątkiem. Z kolei (x / 4 == 0) to nie jest dobry sposób na sprawdzenie podzielności przez 4 – to wyrażenie zwraca prawdę tylko wtedy, gdy x mieści się w przedziale od 0 do 3, bo reszta z dzielenia (modulo) to coś zupełnie innego niż wynik dzielenia całkowitego. W takich przypadkach, zamiast sprawdzić czy liczba dzieli się bez reszty przez 4, sprawdzamy, czy daje wynik zero po dzieleniu całkowitym, co nie ma sensu w tym kontekście. Często takie błędy wynikają z braku rozróżnienia pomiędzy operatorami arytmetycznymi i logicznymi, a także nieuważnym czytaniem polecenia zadania. Operator '||' (lub) sprawia, że wymagania stają się zbyt luźne, a operator '/' sam w sobie nie sprawdza podzielności. Warto zawsze pamiętać o sprawdzaniu pełnej zgodności warunku z wymaganiami zadania – zarówno od strony zakresu liczby, jak i podzielności. Dobrą praktyką jest testowanie tych warunków na konkretnych liczbach i analizowanie wyników, bo wtedy łatwiej wychwycić takie niuanse. Z mojego doświadczenia wynika, że im bardziej przejrzysty i jednoznaczny warunek, tym mniej później błędów podczas pracy z kodem, zwłaszcza gdy trafia on do większego projektu czy zespołu, gdzie czytelność odgrywa ogromną rolę. Takie błędy pojawiają się często na egzaminach czy w pracy początkujących programistów, ale z czasem nabiera się wprawy, żeby podchodzić do nich z większą świadomością i dokładnością.
