Znaczące nazwy funkcji i zmiennych
Warunek zaliczenia
Umiem, gdy w kodzie nie ma nazw x, tab, tablica, foo, a, fun ani kolekcja; wyjątki dopuszczone przez CKE to bufor, tmp i iteratory pętli.
Warto wiedzieć
Kryteria R.1.3 i R.1.4. Kryterium łamie się dopiero wtedy, gdy nazwy nic nie znaczą.
Co dokładnie sprawdza egzaminator
Cytaty dosłowne z zasad oceniania. Brzmienie sprawdzone w zasadach do 20 arkuszy z sesji 2021 do 2026, czyli w całym inwentarzu na dysku.
Użyto znaczące nazewnictwo funkcji lub metod
zasady oceniania INF.04-02-23.06-SG, arkusz kalkulacyjny CKEOd sesji Zima 2024 dochodzi wskazanie języka: „Użyto polskie lub angielskie nazewnictwo funkcji. Nazewnictwo jest znaczące”; wcześniej brzmiało to samo „Zastosowano znaczące nazewnictwo funkcji”. Część sesji mówi wyłącznie o metodach (INF.04-01-25.01-SG, INF.04-01-26.01-SG), część o metodach i funkcjach razem. Zakres jest ten sam: oceniane są nazwy podprogramów, które napisałeś sam.
Użyto znaczące nazewnictwo zmiennych. Wyjątkami od reguły są zmienne bufor, tmp, iteratory pętli itp. Kryterium nie jest spełnione tylko wtedy, gdy nazwy zmiennych nic nie znaczą, np. x, a, tab, tablica, fun
zasady oceniania INF.04-02-23.06-SG, arkusz kalkulacyjny CKELista przykładów jeździ między sesjami: raz jest w niej „a”, raz „foo”, raz „kolekcja”. Ważniejsze są dopiski: INF.04-01-23.01-SG dopuszcza wprost „nazewnictwo dwóch zmiennych algorytmu: a i b”, INF.04-01-23.06-SG dodaje „dopuszcza się aby tablica była nazwana A - zgodnie z pseudokodem”, INF.04-01-24.01-SG wymienia jako wyjątek „zmienne wynikające z algorytmu: S, M, R”, a INF.04-01-25.01-SG zastrzega „klasa i pole tablicowe klasy może mieć nazwę ogólną np tab, tablica itp”. Od INF.04-01-25.06-SG kryterium nie jest spełnione także wtedy, „gdy zmienne nie istnieją”.
3 uwagi ogólne, które zmieniają czytanie kryteriów
- Tolerancja
- Wystarczy, że sprawdzaną cechę zastosowano dla większości (90%) przypadków w kodzie
- Zakres
- Kryteria dotyczą wyłącznie samodzielnie napisanego kodu
- Zastępstwo
- kryteria należy odnieść do aplikacji konsolowej, jeżeli ta nie istnieje, kryteria 1.1 do 1.6 zastosować do aplikacji mobilnej
Po co to jest
To są dwa kryteria z dwudziestu arkuszy na dwadzieścia, dokładnie tak samo jak formatowanie z działu A1. Razem z formatowaniem daje to cztery kryteria dostawane za sam sposób zapisu, zanim program cokolwiek policzy.
Dwa kryteria znaczy dwa pola na karcie oceny. R.1.3 pyta o nazwy funkcji i metod, R.1.4 o nazwy zmiennych i pól. Traci się je osobno i osobno się je odzyskuje: kod z jedną wzorowo nazwaną funkcją i kilkunastoma zmiennymi nazwanymi literami dostaje T przy pierwszym kryterium i N przy drugim. Warto o tym wiedzieć przy poprawianiu na ostatnią chwilę, bo dwie minuty włożone w nazwy zmiennych ratują całe drugie pole.
Katalog strat punktowych wymienia ten błąd jako E.4 i podpowiada jedną czynność: przed oddaniem przeszukać kod po nazwach jednoliterowych poza iteratorami. To jest zadanie na trzy minuty i nie wymaga rozumienia własnego algorytmu.
Pojęcie
Kryterium nie mówi „nazwy mają być ładne” i nie mówi „nazwy mają być długie”. Zdanie, na którym wszystko się opiera, brzmi: „Kryterium nie jest spełnione tylko wtedy, gdy nazwy zmiennych nic nie znaczą”. Słowo „tylko” jest tu najważniejsze i ustawia poprzeczkę nisko: to nie jest recenzja stylu, to jest jeden sprawdzian graniczny.
Sprawdzian brzmi: czy z samej nazwy da się powiedzieć, co pod nią leży. Nazwa, która pasuje do dowolnego programu, nie znaczy nic. x pasuje wszędzie. oceny pasuje tylko tam, gdzie naprawdę leżą oceny. Między jednym a drugim nie ma nic do dyskutowania i dlatego to kryterium da się spełnić bez wyczucia językowego.
Kryterium samo wymienia trzy wyjątki: `bufor`, `tmp` i iteratory pętli. Te trzy są bezpieczne zawsze i we wszystkich przejrzanych sesjach. Zmiennej pomocniczej przy zamianie elementów miejscami nie trzeba więc nazywać pomocnicza; bufor jest wymieniony w zasadach oceniania wprost, a i w nagłówku pętli nie jest w ogóle przedmiotem oceny.
Lista nazw zakazanych nie jest listą. To są przykłady, i to przykłady zmienne: w jednej sesji CKE pisze „np. x, a, tab, tablica, fun”, w innej „np. x, fun, foo, tab, tablica”, w jeszcze innej samo „np. x”. Uczenie się ich na pamięć jest pułapką, bo poza tą listą leży cała reszta nazw, które też nic nie znaczą: dane1, zmienna2, obiekt.
W drugą stronę lista bywa rozszerzana przez samo zadanie. Gdy w arkuszu stoi pseudokod, zasady oceniania potrafią dopuścić jego nazwy wprost. W INF.04-01-23.01-SG dopuszczone są zmienne a i b algorytmu Euklidesa, w INF.04-01-23.06-SG tablica nazwana A zgodnie z pseudokodem, w INF.04-01-24.01-SG zmienne S, M i R. Nazwa przeniesiona z pseudokodu jest więc bezpieczna, a przemianowanie jej bywa gorsze niż zostawienie, bo egzaminator porównuje kod z tym samym pseudokodem.
Języka nazw nikt nie narzuca i nikt nie wymaga konsekwencji. Kryterium mówi „polskie lub angielskie”, więc policzSume i countSum są równie dobre, a jedno obok drugiego w tym samym pliku nie łamie niczego. To jest różnica wobec R.1.1, gdzie konsekwencja jednej wybranej konwencji klamr jest wymagana wprost. Tam liczy się jednolitość, tutaj wyłącznie znaczenie.
Od sesji Lato 2025 doszedł drugi sposób na stracenie R.1.4: brak zmiennych. Zapis kryterium brzmi „gdy zmienne nie istnieją lub ich nazwy nic nie znaczą”. Program, który cały rachunek upycha w jednym wyrażeniu, nie ma czego nazwać i przez to nie spełnia kryterium.
Zobacz to dwa razy
Ten sam program, to samo formatowanie, ten sam algorytm i ta sama liczba linii. Różnią się wyłącznie nazwy. To sortowanie bąbelkowe z arkusza INF.04-02-23.06-SG, czyli z tego, z którego pochodzą oba cytowane wyżej kryteria.
void fun(int tab[], int x){ for (int i = 0; i < x - 1; i++) { for (int j = 0; j < x - 1 - i; j++) { if (tab[j] > tab[j + 1]) { int a = tab[j]; tab[j] = tab[j + 1]; tab[j + 1] = a; } } }}- ! linia 1Trzy nazwy z listy CKE w jednej linii: `fun` łamie R.1.3, a `tab` i `x` łamią R.1.4. Jedna linia kosztuje tu oba kryteria naraz.
- + linia 3Iteratory `i` oraz `j` są w porządku i zostaną bez zmiany także w wersji poprawionej. Kryterium wymienia iteratory pętli jako wyjątek od reguły.
- ! linia 9`a` to zmienna buforowa nazwana literą, a kryterium wymienia `a` wprost jako przykład nazwy, która nic nie znaczy. Poprawka jest tu darmowa, bo `bufor` jest z kolei wymieniony jako wyjątek.
void sortujRosnaco(int liczby[], int rozmiar){ for (int i = 0; i < rozmiar - 1; i++) { for (int j = 0; j < rozmiar - 1 - i; j++) { if (liczby[j] > liczby[j + 1]) { int bufor = liczby[j]; liczby[j] = liczby[j + 1]; liczby[j + 1] = bufor; } } }}- + linia 1Nazwa funkcji mówi, co funkcja robi, a nazwy argumentów mówią, co przyjmuje. Jedna poprawiona linia zamyka R.1.3 i połowę R.1.4.
- + linia 9`bufor` jest wymieniony w treści kryterium jako wyjątek, więc jest bezpieczny nawet przy ostrym czytaniu.
Mostek: zdanie kryterium wobec linii kodu
| Fragment kryterium | Gdzie się łamie | Gdzie jest spełniony |
|---|---|---|
| znaczące nazewnictwo funkcji lub metod (kryterium R.1.3) | fun w linii 1, nazwa, która pasuje do dowolnego programu | sortujRosnaco w linii 1, czasownik plus sposób |
| nazwy zmiennych nic nie znaczą, np. x, a, tab, tablica, fun | tab i x w linii 1 oraz a w linii 9, czyli trzy z pięciu nazw wymienionych w zasadach | liczby, rozmiar i bufor w tych samych miejscach |
| Wyjątkami od reguły są zmienne bufor, tmp, iteratory pętli | i i j w liniach 3 i 5 są poprawne już w tej wersji | i i j zostają nietknięte, zmienia się tylko a na bufor |
Granice
Kod, którego nie napisałeś, się nie liczy. Uwaga ogólna mówi, że kryteria dotyczą wyłącznie samodzielnie napisanego kodu. Nazwy w szkielecie projektu, w plikach pośrednich środowiska i w bibliotekach nie są oceniane. Nie ma sensu ich zmieniać i nie ma się czego bać, gdy wyglądają inaczej niż Twoje.
To nie jest kryterium o wielkości liter ani o stylu zapisu nazw. liczbaOcen, liczba_ocen i LiczbaOcen spełniają je tak samo. Konwencje nazewnicze języka są dobrym nawykiem, ale w zasadach oceniania nie ma o nich ani słowa.
To nie jest kryterium o poprawności językowej. Nazwa z literówką albo bez polskich znaków nadal znaczy to, co znaczy. liczbaOcen i liczbaOcem przechodzą oba, choć drugie boli.
To nie jest kryterium o formatowaniu ani o typach. Zapis kodu to R.1.1 i R.1.2, czyli dział A1, a dobór typów to R.1.5, czyli A3. Kod z wzorowymi nazwami i zerem wcięć traci tamte, a te zachowuje.
Aplikacja złożona z samego kodu wygenerowanego też nie ratuje przed tymi kryteriami. Uwaga ogólna w INF.04-01-26.06-SG mówi o aplikacji konsolowej, która „nie istnieje lub zawiera tylko kod wygenerowany”, i przenosi kryteria na następną część. Pusty szkielet projektu nie jest więc oddaniem części pierwszej i nie zdejmuje z Ciebie R.1.3 ani R.1.4.
Nie-przykład, który mylnie wygląda na ten sam problem: nazwa krótka. Krótkość nie jest zarzutem. ile, suma i koniec są krótkie i znaczą wszystko, co trzeba, a daneWejscioweUzytkownika jest długie i mówi mniej niż pesel.
W czterech językach
Arkusz dopuszcza C++, C#, Javę i Pythona. Kryterium jest jedno, ale w każdym z nich wygląda trochę inaczej.
- C++
- Argumenty tablicowe najczęściej lądują jako
tab[]in, bo tak wyglądają w podręcznikach.tabjest wymienione w zasadach wprost, więc to najczęstsza pojedyncza strata w tym dziale. - C#
- Właściwości i pola publiczne pisze się w tym języku od wielkiej litery. Kryterium tego nie dotyczy, więc
Ocenyiocenysą równie dobre; liczy się to, że nie są nazwaneTab. - Java
- Szablon klasy generowany przez środowisko wstawia
argsw nagłówku metody głównej. To nazwa narzucona przez język, a nie wybrana przez zdającego, więc nie ma czego poprawiać. - Python
- Nie ma tu deklaracji typu, więc nazwa jest jedyną informacją o zawartości zmiennej i kryterium waży o tyle więcej.
selfw metodach jest nazwą narzuconą przez język i nie podlega ocenie.
Procedura
Nazwy wybiera się w trakcie pisania, a nie po nim, bo poprawianie ich na końcu wymaga przejścia przez każde wystąpienie. Ostatni krok jest wyjątkiem: to przeszukanie kontrolne, które robi się po wszystkim i które ratuje kryterium, gdy poprzednie kroki się nie udały.
- 1
Nazwę funkcji zbuduj z czasownika i dopełnienia, tak jak brzmi polecenie w zadaniu.
wolno tak, bo kryterium pyta o znaczenie nazwy, a nazwa z czasownikiem mówi o działaniu funkcji z definicji; polecenie w arkuszu podaje ten czasownik gotowy.
- 2
Zmienną nazwij tym, co w niej leży, a nie tym, jakiego jest typu.
wolno tak, bo typ widać z deklaracji, więc
tablicaLiczbpowtarza informację, którą kompilator już ma, aocenydokłada tę, której nie ma nikt. - 3
Nazwy przeniesione z pseudokodu w zadaniu zostaw bez zmiany.
wolno tak, bo zasady oceniania dopuszczają je wprost w sesjach, w których pseudokod ich używa, a przemianowanie utrudnia egzaminatorowi porównanie Twojego kodu z arkuszem.
- 4
Zmienną pomocniczą przy zamianie miejscami nazwij
buforalbotmp.to konwencja, bo obie nazwy są wymienione w treści kryterium jako wyjątek, więc nie podlegają ocenie wcale, a ta sama zmienna nazwana
aalbopstoi na liście przykładów po przeciwnej stronie. - 5
Przed oddaniem przeszukaj plik po nazwach jednoliterowych spoza nagłówków pętli.
wolno tak, bo to jedno przeszukanie łapie większość strat z tego działu, trwa trzy minuty i nie wymaga rozumienia własnego algorytmu.
Co widzę, więc co robię
| Widzę | Robię |
|---|---|
Nazwa funkcji jest rzeczownikiem albo skrótem: fun, dane, oblicz1 | Zamień na czasownik z dopełnieniem: policzSume |
| Zmienna nazwana jedną literą poza nagłówkiem pętli | Przemianuj, chyba że litera pochodzi z pseudokodu zadania |
| Zmienna pomocnicza przy zamianie elementów miejscami | Nazwij ją bufor albo tmp |
Tablica albo kolekcja nazwana tab, tablica, kolekcja | Nazwij ją tym, co w niej leży: oceny, pytania, losowania |
| Kod gotowy, zostało kilka minut przed oddaniem | Przeszukaj plik po x, a, tab, tablica, foo, fun, kolekcja |
Drugi wiersz ma wyjątek nie bez powodu: przemianowanie zmiennej, którą samo zadanie nazywa `a`, potrafi zaszkodzić, bo egzaminator zestawia kod z pseudokodem z arkusza.
Ćwiczenia
Trzy stopnie, w każdym mniej pomocy niż w poprzednim. Odpowiedź jest schowana celowo: zajrzyj do niej po własnej próbie, nie przed.
1Przykład z omówieniem
Przeczytaj funkcję i rozstrzygnij osobno dla R.1.3 i osobno dla R.1.4, czy kryterium jest spełnione. Uwaga: nie oba przepadają.
Fragment liczący średnią z tablicy double policzSrednia(int tab[], int n){ int suma = 0; for (int i = 0; i < n; i++) { suma = suma + tab[i]; } return (double)suma / n;}Pokaż odpowiedź
R.1.3 jest spełnione:
policzSredniamówi, co funkcja robi. R.1.4 przepada, i to na jednej nazwie.sumajest znacząca,ijest wyjątkiem wymienionym w kryterium, aletabstoi w zasadach oceniania jako przykład nazwy, która nic nie znaczy. Osobno warto zobaczyćn: tej nazwy CKE nie wymienia na żadnej liście, więc rozstrzygałby ją egzaminator. Nic nie kosztuje nazwać jąrozmiari nie zostawiać mu tej decyzji.2Znajdź resztę sam
W tym fragmencie są cztery nazwy, które na pierwszy rzut oka wyglądają na złamanie kryterium. Trzy z nich są bezpieczne. Wskaż tę czwartą i podaj numer linii.
Algorytm Euklidesa z arkusza INF.04-01-23.01-SG, z dołożonym licznikiem int nwd(int a, int b){ int tmp = 0; int x = 0; while (b != 0) { tmp = a % b; a = b; b = tmp; x = x + 1; } cout << "Liczba krokow: " << x << endl; return a;}Wskazówka: Trzy z tych nazw mają w zasadach oceniania osobne zdanie na swoją obronę. Czwarta jest w nich wymieniona po przeciwnej stronie.
Pokaż odpowiedź
Czwarta to
xz linii 4, licznik kroków.aibsą bezpieczne, bo zasady oceniania tego arkusza dopuszczają je wprost jako zmienne algorytmu, atmpjest wyjątkiem wymienionym w treści samego kryterium.xnie ma żadnej takiej ochrony i stoi na liście przykładów. Nazwij golicznikKrokow.3Zadanie
Zadanie brzmiało: policz, ile razy w tablicy ocen występuje ocena celująca. Przepisz nazwy tak, żeby kod spełniał oba kryteria. Nie zmieniaj ani jednej instrukcji: zmieniasz wyłącznie nazwy. Potem porównaj z rozwiązaniem i postaw sobie T albo N osobno przy R.1.3 i osobno przy R.1.4.
Cztery nazwy do zmiany i jedna, której zmieniać nie wolno int fun(int tab[], int x){ int a = 0; for (int i = 0; i < x; i++) { if (tab[i] == 6) { a = a + 1; } } return a;}Pokaż odpowiedź
Do zmiany są cztery nazwy:
fun,tab,xia. Iteratorizostaje. Jeżeli Twoje nazwy różnią się od poniższych, ale każda mówi, co przechowuje albo co robi, jest równie poprawnie: to kryterium nie ma jednej właściwej odpowiedzi, tylko granicę, poniżej której nazwa nie znaczy nic.Pokaż rozwiązanie w kodzie
Jedno z poprawnych rozwiązań int policzOcenyCelujace(int oceny[], int liczbaOcen){ int celujacych = 0; for (int i = 0; i < liczbaOcen; i++) { if (oceny[i] == 6) { celujacych = celujacych + 1; } } return celujacych;}- + linia 5Iterator `i` został bez zmiany. Kryterium wymienia iteratory pętli jako wyjątek, więc przemianowanie go na `indeks` nic nie dokłada i tylko kosztuje czas.
Laboratorium
Popraw nazwy w poniższym fragmencie tak, żeby przeszedł oba kryteria, i sprawdź go przyciskiem. Możesz też wyczyścić pole i wkleić własny kod. Pole nad przyciskiem służy do wpisania nazw, które zasady oceniania Twojego zadania dopuszczają wprost: bez tego sprawdzarka zgłosi nazwę z pseudokodu, którą egzaminator przyjąłby bez uwag.
Sprawdzenie rusza dopiero po naciśnięciu przycisku, nie przy pisaniu. Na egzaminie takiego narzędzia nie będzie, więc próba ma być najpierw własna.
Edytor wczytuje się w przeglądarce.
Pułapka
„Nauczyłem się listy nazw zakazanych: x, a, tab, tablica, foo, fun, kolekcja. Wystarczy, że nie użyję żadnej z nich, i mam R.1.3 oraz R.1.4 z głowy.”
Ta reguła myli się w obie strony i w obie strony kosztuje.
Poniższa funkcja nie używa ani jednej nazwy z tej listy i mimo to nie spełnia R.1.4, bo żadna z jej nazw nic nie znaczy. Lista CKE to przykłady, a nie zakres. W drugą stronę działa to tak samo: w INF.04-01-25.01-SG pole tablicowe klasy wolno nazwać tab, a w INF.04-01-23.01-SG zmienne algorytmu wolno nazwać a i b, bo tak nazywa je samo zadanie.
void przetworz(int dane1[], int dane2, int zmienna1){ int zmienna2 = 0; for (int i = 0; i < dane2; i++) { zmienna2 = zmienna2 + dane1[i]; } zmienna1 = zmienna2;}Reguła poprawna
Kryterium nie jest listą zakazanych słów, tylko jednym zdaniem o znaczeniu: „Kryterium nie jest spełnione tylko wtedy, gdy nazwy zmiennych nic nie znaczą”. Sprawdzian jest zawsze ten sam, niezależnie od sesji i od tego, czy nazwa stoi na jakiejś liście: czy z samej nazwy da się powiedzieć, co pod nią leży. Listy w zasadach oceniania są ilustracją tego zdania, a nie jego treścią.
Sprawdź się
Odpowiadaj na głos albo na kartce, zanim odsłonisz. Odtworzenie z pamięci jest tym, co buduje trwałość, a przeczytanie odpowiedzi tylko przypomina, że się ją widziało.
- 1
Które trzy rodzaje nazw kryterium wymienia jako wyjątki od reguły?
z pamięci
Pokaż odpowiedź
Zmienne
buforitmporaz iteratory pętli. Te trzy są wymienione w treści kryterium i powtarzają się we wszystkich przejrzanych sesjach. - 2
Ile kryteriów dotyczy nazewnictwa i czego dotyczy każde z nich?
z pamięci
Pokaż odpowiedź
Dwa. R.1.3 dotyczy nazw funkcji i metod, R.1.4 nazw zmiennych i pól. To dwa osobne pola na karcie oceny, więc traci się je i odzyskuje niezależnie.
- 3
W zadaniu jest pseudokod, w którym tablica nazywa się
A. Nazwać ją w kodzieAczyoceny?wykonanie i uzasadnienie
Pokaż odpowiedź
A. Zasady oceniania INF.04-01-23.06-SG dopuszczają to wprost słowami „dopuszcza się aby tablica była nazwana A - zgodnie z pseudokodem”, a zgodność z pseudokodem ułatwia egzaminatorowi zestawienie Twojego kodu z arkuszem. Zmiana nazwy nie daje tu nic i może zaszkodzić. - 4
Nazwałeś funkcje po angielsku, a zmienne po polsku. Czy to łamie któreś z dwóch kryteriów?
wykonanie i uzasadnienie
Pokaż odpowiedź
Nie. Kryterium mówi „polskie lub angielskie” i nie żąda jednolitości. To jest różnica wobec R.1.1, gdzie konsekwencja jednej wybranej konwencji klamr jest wymagana wprost. Przy nazwach liczy się wyłącznie znaczenie.
- 5
Twój program nie ma ani jednej zmiennej, bo cały rachunek mieści się w jednym wyrażeniu. Co z kryterium R.1.4?
wykonanie i uzasadnienie
Pokaż odpowiedź
Od INF.04-01-25.06-SG kryterium nie jest spełnione także wtedy, „gdy zmienne nie istnieją”. Rozbicie rachunku na dwie nazwane zmienne kosztuje jedną linię i ratuje całe pole.
Kiedy umiem
Warunki obserwowalne. Dopóki któryś nie jest spełniony, dział zostaje w toku, nawet jeżeli materiał wydaje się oczywisty.
- W kodzie pisanym na czas, trzy razy pod rząd, przeszukanie pliku po siedmiu nazwach z listy CKE nie daje ani jednego trafienia poza nagłówkami pętli.
- Wymieniam z pamięci trzy wyjątki z treści kryterium i mówię, które kryterium dotyczy funkcji, a które zmiennych, bez zaglądania do tej lekcji.
- Czytając pseudokod z arkusza, wskazuję nazwy, które przeniosę do kodu bez zmiany, i uzasadniam to zdaniem z zasad oceniania.
- Po co najmniej siedmiu dniach od tej lekcji, przy zamkniętym materiale, poprawiam nazwy w podanym fragmencie i nie przemianowuję ani iteratora pętli, ani zmiennej buforowej.
- Po próbie arkusza stawiam sobie osobno T albo N przy R.1.3 i osobno przy R.1.4, wskazując przy każdym konkretną nazwę, która ten werdykt uzasadnia.
Źródła
- Zasady oceniania CKE do arkuszy INF.04, sesje 2021 do 2026, 20 arkuszy; brzmienie kryteriów nazewniczych sprawdzone w każdym z nich
- Arkusz kalkulacyjny zasad oceniania INF.04-02-23.06-SG, z którego pochodzi dosłowny cytat obu kryteriów
- Warianty brzmienia i dopiski o wyjątkach: INF.04-01-23.01-SG (zmienne `a` i `b`), INF.04-01-23.06-SG (tablica `A` zgodna z pseudokodem), INF.04-01-24.01-SG (zmienne `S`, `M`, `R`), INF.04-01-25.01-SG (pole tablicowe klasy), INF.04-01-25.06-SG (zmienne, które nie istnieją)
- Uwagi ogólne do rezultatu 1: tolerancja 90 procent, zakres samodzielnie napisanego kodu, przeniesienie kryteriów przy braku aplikacji konsolowej
- Katalog strat punktowych E.4 z pliku wiedzy 01, sekcja 10
- Ścieżka nauki programowania, plik wiedzy 07, dział A2: kryteria obecne w 20 arkuszach z 20