Zadania INF03 - Proszę o opinię , co byście zmienili , dodali.

Question

Cześć wszystkim,
wrzuciłem rozwiązania zadań egzaminacyjnych INF.03 (HTML, CSS, PHP, MySQL). Zrobiłem to głównie dla siebie, żeby się uczyć programowania, kodu, logiki – krok po kroku.

 Nie udaję eksperta. To nie poradnik z YouTube. To moje prawdziwe próby, błędy i nauka.
 Staram się wszystko rozpisywać – co robi dany kod, dlaczego coś działa albo nie działa.

Po co to wrzucam?
 Chcę się uczyć szybciej, ale nie sam – szukam feedbacku, wskazówek, krytyki, podpowiedzi:
– Gdzie robię błędy?
– Co można poprawić?
– Jak lepiej pisać kod i się uczyć?
– Co jeszcze dodać do tych rozwiązań?

Jak ktoś też się uczy – zapraszam, może Wam to coś da. Jak ktoś jest lepszy – to serio: pomóż mi ogarnąć ten temat jak człowiek.

 Repozytorium z moimi rozwiązaniami:
 https://github.com/Jabloniaczek/INF03

Comments

Piszesz, że masz rozwiązania z kwalifikacji INF.03, a podajesz jakieś archaizmy sprzed 10 i więcej lat z kwalifikacji E.14.

---

"Piszesz, że mam rozwiązania z kwalifikacji INF.03" – a co dokładnie chciałbyś tu zobaczyć? Nie wiem, jak to zrozumiałeś.

Rozwiązuję arkusze egzaminacyjne, także te starsze (czyli, jak piszesz, „archaizmy”), bo jako osoba początkująca uważam, że na start są trochę łatwiejsze i uczą podstaw.

Ty pewnie od razu zaczynałeś od exploitów w Assemblerze i debuggera na Commodore 64  – no niestety, nie każdy może być tak zajebisty jak Ty

---

Chciałbym zobaczyć to, co podałeś w tytule, czyli rozwiązania zadań z kwalifikacji INF.03, a nie E.14, której już nie ma. Tytuł posta zatem jest mylący, tak samo opisy commitów w twoim repo. Zadania INF.03 a zadania E.14 to zupełnie różny poziom trudności, zwłaszcza w sesji letniej, gdy zdaje programista.

Obniż poziom agresji, to ty chciałeś feedbacku, ale nie zaznaczyłeś, że interesują cię tylko zachwyty.

Własność float stosuj tylko do tego, do czego została ona przewidziana, czyli z grubsza odpływania np. grafiki względem tekstu. Strona oparta na znacznikach div, do tego z identyfikatorami używanymi do stylowania obecnie nie przejdzie - masz wprost wymóg stosowania znaczników semantycznych HTML5. Podsumowując, unowocześnij technologię tworzenia stron do obecnych standardów egzaminacyjnych. I trenuj odporność na krytykę, która ponadto nie ma na celu poniżania twojej osoby, lecz ocenę twojej pracy.

---

"Piszesz, że masz rozwiązania z kwalifikacji INF.03, a podajesz jakieś archaizmy sprzed 10 i więcej lat z kwalifikacji E.14." nie wiedziałem , że to aż takie rażące jest dla Ciebie . Prosiłem o feedback a nie przyczepianie się do nazw. Mniejsza w to . Co do reszty na pewno się dostosuję :-) czyli stosowania semantycznych znaczników :-) i używania nowocześniejszych technologii :-)

---

Ponieważ E.14 to już archaizm. Rażące natomiast jest dla mnie wprowadzanie w błąd ewentualnego użytkownika twojej pracy (być może niezamierzone). Czego można się spodziewać po opisie commitu Dodano pliki PDF z egzaminów INF.03, bo chyba nie rozwiązania zadania z kwalifikacji E.14? Popraw to może i będzie uczciwiej wobec korzystających.

Answer 1

Z góry - fajnie, że nie boisz się szukać feedbacku u innych.
Tak +- co można poprawić w repo, które podesłałeś:

- Formatowanie i czytelność
Większość współczesnych edytorów ma wbudowane formatowanie, a co więcej - pomagają utrzymać w miarę sformatowany kod, gdy go piszesz. Osobiście polecam darmowy Visual Studio Code od Microsoftu.
Przykład takiego formatowania: Visual Studio Code + rozszerzenie Prettier

Głównie problemem jest nadmiar pustych linijek i formatowanie bloków. Patrząc na to:

if(podajHaslo===haslo){ //sprawdzamy czy wprowadzona wartosc zgadza sie z ta zadeklarowana wczesniej
    let jakaLiczba = parseInt(prompt("Podaj liczbę")); //uzytkownik podaje kolejna wartosc i konwertujemy to zgodnie z logiką na liczbę
if(isNaN(jakaLiczba)){ // sprawdzamy czy liczba to liczba funkcą is nan . 
    alert("To nie jest liczba"); // wyswietlamy alerty jesli wartosc jest inna niz liczba 
    return;
}

Ciężko mi zobaczyć, że kod pod spodem (check ifNaN) jest w bloku, w którym sprawdzasz hasło (co więcej, formatowanie tutaj sugeruje, że jest odwrotnie). Lepiej jest tak:

if (podajHaslo === haslo) {
    //sprawdzamy czy wprowadzona wartosc zgadza sie z ta zadeklarowana wczesniej
    let jakaLiczba = parseInt(prompt("Podaj liczbę")); //uzytkownik podaje kolejna wartosc i konwertujemy to zgodnie z logiką na liczbę
    if (isNaN(jakaLiczba)) {
        // sprawdzamy czy liczba to liczba funkcą is nan .
        alert("To nie jest liczba"); // wyswietlamy alerty jesli wartosc jest inna niz liczba
        return;
    }

Bo poprostu łatwiej zrozumieć, co się dzieje. A już w ogóle, gdy masz duży blok w ifie (if (podajHaslo === haslo)), to może lepiej byłoby go zastąpić ifem z returnem (co swoją drogą już robisz przy isNaN).
Wtedy zamiast

if (podajHaslo === haslo) {
    /* reszta kodu */
}

robi się

if (podajHaslo !== haslo) return;

/* reszta kodu */

i w dużej ilości przypadków to też wygodniej czytać.
 

- Nadmierne komentarze

if(liczbaPoczatkowa < liczbaKoncowa){ //co ma sie stac w programie jesli liczba poczatkowa mniejsza od liczby koncowej

Generalnie, komentarze powinno używać się wtedy, kiedy naprawdę potrzeba (tj. wtedy, gdy pomagają zrozumieć "trudny" kawałek kodu) - kod powinien "sam się komentować". W tym przypadku kod i komentarz mówią dokładnie to samo, nie wnosi to kompletnie nic.

- Opisywanie commitów
W twoim repo każdy commit ma opis "Dodano pliki PDF z egzaminów INF.03", gdzie każdy commit dodaje egzamin z danej daty.
Lepszy jest opis w stylu "Rozwiązanie arkuszu ze stycznia 2015". Jeżeli w commicie masz kilka zmian, to wtedy krótko wzmieniasz je w opisie.
Warto też stosować się do jakiegoś standardu, przykładowo Conventional Commits.

Comments

W kolejnych arkuszach/wersjach będę się starał – a nawet na pewno – zacznę to wprowadzać w życie. Dzięki za szczerą opinię i za to, że nie byłeś jedną z tych osób, które tylko wyśmiewają, ale rzeczywiście doradziłeś i dałeś wartościowe wskazówki