1 <script>
2 const liczba = 1;
3 let gora = 10, dol = 1;
4 let podaj = parseInt(prompt("Podaj liczbę całkowitą z zakresu <1-10>"));
5 liczba = Math.random() * ( gora - dol + 1 ) + dol;
6 liczba = parseInt(liczba);
7 if (liczba == podaj) {
8 document.write("Liczba została odgadnięta");
9 } else {
10 document.write("Niestety nie tym razem");
11 }
12 </script>
Przedstawiony fragment kodu JavaScript powinien wylosować liczbę całkowitą z zakresu <1 , 10> i porównać ją z liczbą podaną przez użytkownika w oknie dialogowym. Skrypt po uruchomieniu generuje błąd, którego przyczyną jest Przyczyną błędu w tym skrypcie jest próba nadpisania stałej zadeklarowanej słowem kluczowym const. W drugiej linii kodu mamy `const liczba = 1;`, czyli tworzymy stałą o nazwie `liczba` i nadajemy jej wartość początkową 1. Zgodnie ze specyfikacją ECMAScript, zmienne zadeklarowane przez `const` nie mogą być później modyfikowane poprzez przypisanie. Innymi słowy: raz ustawiona wartość const jest niezmienna. Tymczasem w piątej linii skryptu występuje instrukcja `liczba = Math.random() * (gora - dol + 1) + dol;`, która dokładnie próbuje przypisać nową wartość do tej stałej. Przeglądarka reaguje na to błędem typu `TypeError` lub `Assignment to constant variable`, i skrypt się sypie zanim w ogóle dojdzie do porównania z wartością wprowadzoną przez użytkownika. W praktyce, jeśli chcemy losować liczbę, zmienna powinna być zadeklarowana przez `let` lub `var`, np. `let liczba;` w drugiej linii, a dopiero potem przypisywać wartość wylosowaną z `Math.random()`. Dobra praktyka jest taka, żeby do `const` dawać rzeczy, które naprawdę nie będą zmieniane w logice programu, np. `const GORA = 10; const DOL = 1;` albo stałe konfiguracyjne, adresy URL API itp. Natomiast zmienne, które w czasie działania skryptu mają się zmieniać (liczniki pętli, wyniki obliczeń, losowania), deklarujemy jako `let`. Z mojego doświadczenia jednym z częstszych błędów początkujących jest właśnie mechaniczne używanie `const` „bo jest nowoczesne” bez zrozumienia, że to blokuje późniejsze przypisania. Warto też zauważyć, że sama konstrukcja losowania liczby całkowitej z przedziału <1,10> jest poprawna: `Math.random()` daje liczbę z zakresu <0,1), potem skalujemy ją do odpowiedniego przedziału i na końcu obcinamy część ułamkową przez `parseInt` lub lepiej `Math.floor`. Gdyby `liczba` była zadeklarowana jako `let`, skrypt by działał zgodnie z założeniami.W tym zadaniu łatwo skupić się na szczegółach, które wyglądają podejrzanie, ale w rzeczywistości są poprawne. Wiele osób patrzy najpierw na deklarację zmiennych `gora` i `dol` w trzeciej linii, bo mamy tam dwa identyfikatory zadeklarowane w jednym wierszu: `let gora = 10, dol = 1;`. Taka składnia w JavaScript jest całkowicie poprawna i bardzo często spotykana w kodzie produkcyjnym. Standard ECMAScript dopuszcza deklarację wielu zmiennych w jednym instrukcie `let`, `const` czy `var`, oddzielonych przecinkami. To nie ma żadnego wpływu na poprawność działania skryptu, jest tylko kwestią stylu kodowania. Niektórzy lintersi zalecają jedną zmienną na linię, ale to jest wyłącznie konwencja, nie błąd.
Podobnie z instrukcją warunkową `if ... else`. Konstrukcja `if (liczba == podaj) { ... } else { ... }` jest jak najbardziej poprawna składniowo. Nawet użycie operatora `==` (zamiast bardziej restrykcyjnego `===`) nie powoduje tu błędu wykonania, najwyżej może być dyskusyjne ze względu na dobre praktyki, bo `===` nie robi konwersji typów. Jednak w tym konkretnym kodzie obie wartości są konwertowane do liczb, więc porównanie zadziała logicznie. Błąd wykonania nie ma więc źródła w warunku.
Czasem pojawia się też myśl, że problemem może być `parseInt(prompt(...))`, bo prompt zwraca tekst. Tymczasem właśnie dlatego używamy `parseInt`, żeby zamienić łańcuch znaków na liczbę całkowitą. Bez tej konwersji porównywalibyśmy liczbę z tekstem, co mogłoby dawać dziwne wyniki logiczne. Konwersja jest tu więc nie tylko „nie niepotrzebna”, ale wręcz wskazana. W nowoczesnym kodzie można by użyć np. `Number(prompt(...))` albo dodatkowo sprawdzić, czy użytkownik faktycznie podał liczbę, ale sam `parseInt` jest jak najbardziej OK.
Sednem problemu nie są więc ani deklaracje `gora` i `dol`, ani składnia `if ... else`, ani konwersja wartości z prompta, tylko próba nadpisania stałej. Z mojego doświadczenia wynika, że to bardzo typowy błąd przy nauce `const` i `let`: mylenie stałych z „zwykłymi” zmiennymi. Warto zawsze zadać sobie pytanie: czy ta wartość ma się zmieniać w czasie działania skryptu? Jeśli tak, używamy `let`. Jeśli nie, wtedy dopiero `const`. To prosta zasada, która pozwala uniknąć takich błędów logicznych i runtime'owych.
1 <script>
2 const liczba = 1;
3 let gora = 10, dol = 1;
4 let podaj = parseInt(prompt("Podaj liczbę całkowitą z zakresu <1-10>"));
5 liczba = Math.random() * ( gora - dol + 1 ) + dol;
6 liczba = parseInt(liczba);
7 if (liczba == podaj) {
8 document.write("Liczba została odgadnięta");
9 } else {
10 document.write("Niestety nie tym razem");
11 }
12 </script>Przyczyną błędu w tym skrypcie jest próba nadpisania stałej zadeklarowanej słowem kluczowym const. W drugiej linii kodu mamy `const liczba = 1;`, czyli tworzymy stałą o nazwie `liczba` i nadajemy jej wartość początkową 1. Zgodnie ze specyfikacją ECMAScript, zmienne zadeklarowane przez `const` nie mogą być później modyfikowane poprzez przypisanie. Innymi słowy: raz ustawiona wartość const jest niezmienna. Tymczasem w piątej linii skryptu występuje instrukcja `liczba = Math.random() * (gora - dol + 1) + dol;`, która dokładnie próbuje przypisać nową wartość do tej stałej. Przeglądarka reaguje na to błędem typu `TypeError` lub `Assignment to constant variable`, i skrypt się sypie zanim w ogóle dojdzie do porównania z wartością wprowadzoną przez użytkownika. W praktyce, jeśli chcemy losować liczbę, zmienna powinna być zadeklarowana przez `let` lub `var`, np. `let liczba;` w drugiej linii, a dopiero potem przypisywać wartość wylosowaną z `Math.random()`. Dobra praktyka jest taka, żeby do `const` dawać rzeczy, które naprawdę nie będą zmieniane w logice programu, np. `const GORA = 10; const DOL = 1;` albo stałe konfiguracyjne, adresy URL API itp. Natomiast zmienne, które w czasie działania skryptu mają się zmieniać (liczniki pętli, wyniki obliczeń, losowania), deklarujemy jako `let`. Z mojego doświadczenia jednym z częstszych błędów początkujących jest właśnie mechaniczne używanie `const` „bo jest nowoczesne” bez zrozumienia, że to blokuje późniejsze przypisania. Warto też zauważyć, że sama konstrukcja losowania liczby całkowitej z przedziału <1,10> jest poprawna: `Math.random()` daje liczbę z zakresu <0,1), potem skalujemy ją do odpowiedniego przedziału i na końcu obcinamy część ułamkową przez `parseInt` lub lepiej `Math.floor`. Gdyby `liczba` była zadeklarowana jako `let`, skrypt by działał zgodnie z założeniami.
W tym zadaniu łatwo skupić się na szczegółach, które wyglądają podejrzanie, ale w rzeczywistości są poprawne. Wiele osób patrzy najpierw na deklarację zmiennych `gora` i `dol` w trzeciej linii, bo mamy tam dwa identyfikatory zadeklarowane w jednym wierszu: `let gora = 10, dol = 1;`. Taka składnia w JavaScript jest całkowicie poprawna i bardzo często spotykana w kodzie produkcyjnym. Standard ECMAScript dopuszcza deklarację wielu zmiennych w jednym instrukcie `let`, `const` czy `var`, oddzielonych przecinkami. To nie ma żadnego wpływu na poprawność działania skryptu, jest tylko kwestią stylu kodowania. Niektórzy lintersi zalecają jedną zmienną na linię, ale to jest wyłącznie konwencja, nie błąd.
Podobnie z instrukcją warunkową `if ... else`. Konstrukcja `if (liczba == podaj) { ... } else { ... }` jest jak najbardziej poprawna składniowo. Nawet użycie operatora `==` (zamiast bardziej restrykcyjnego `===`) nie powoduje tu błędu wykonania, najwyżej może być dyskusyjne ze względu na dobre praktyki, bo `===` nie robi konwersji typów. Jednak w tym konkretnym kodzie obie wartości są konwertowane do liczb, więc porównanie zadziała logicznie. Błąd wykonania nie ma więc źródła w warunku.
Czasem pojawia się też myśl, że problemem może być `parseInt(prompt(...))`, bo prompt zwraca tekst. Tymczasem właśnie dlatego używamy `parseInt`, żeby zamienić łańcuch znaków na liczbę całkowitą. Bez tej konwersji porównywalibyśmy liczbę z tekstem, co mogłoby dawać dziwne wyniki logiczne. Konwersja jest tu więc nie tylko „nie niepotrzebna”, ale wręcz wskazana. W nowoczesnym kodzie można by użyć np. `Number(prompt(...))` albo dodatkowo sprawdzić, czy użytkownik faktycznie podał liczbę, ale sam `parseInt` jest jak najbardziej OK.
Sednem problemu nie są więc ani deklaracje `gora` i `dol`, ani składnia `if ... else`, ani konwersja wartości z prompta, tylko próba nadpisania stałej. Z mojego doświadczenia wynika, że to bardzo typowy błąd przy nauce `const` i `let`: mylenie stałych z „zwykłymi” zmiennymi. Warto zawsze zadać sobie pytanie: czy ta wartość ma się zmieniać w czasie działania skryptu? Jeśli tak, używamy `let`. Jeśli nie, wtedy dopiero `const`. To prosta zasada, która pozwala uniknąć takich błędów logicznych i runtime'owych.
Podobnie z instrukcją warunkową `if ... else`. Konstrukcja `if (liczba == podaj) { ... } else { ... }` jest jak najbardziej poprawna składniowo. Nawet użycie operatora `==` (zamiast bardziej restrykcyjnego `===`) nie powoduje tu błędu wykonania, najwyżej może być dyskusyjne ze względu na dobre praktyki, bo `===` nie robi konwersji typów. Jednak w tym konkretnym kodzie obie wartości są konwertowane do liczb, więc porównanie zadziała logicznie. Błąd wykonania nie ma więc źródła w warunku.
Czasem pojawia się też myśl, że problemem może być `parseInt(prompt(...))`, bo prompt zwraca tekst. Tymczasem właśnie dlatego używamy `parseInt`, żeby zamienić łańcuch znaków na liczbę całkowitą. Bez tej konwersji porównywalibyśmy liczbę z tekstem, co mogłoby dawać dziwne wyniki logiczne. Konwersja jest tu więc nie tylko „nie niepotrzebna”, ale wręcz wskazana. W nowoczesnym kodzie można by użyć np. `Number(prompt(...))` albo dodatkowo sprawdzić, czy użytkownik faktycznie podał liczbę, ale sam `parseInt` jest jak najbardziej OK.
Sednem problemu nie są więc ani deklaracje `gora` i `dol`, ani składnia `if ... else`, ani konwersja wartości z prompta, tylko próba nadpisania stałej. Z mojego doświadczenia wynika, że to bardzo typowy błąd przy nauce `const` i `let`: mylenie stałych z „zwykłymi” zmiennymi. Warto zawsze zadać sobie pytanie: czy ta wartość ma się zmieniać w czasie działania skryptu? Jeśli tak, używamy `let`. Jeśli nie, wtedy dopiero `const`. To prosta zasada, która pozwala uniknąć takich błędów logicznych i runtime'owych.