Przejdź do treści
INF.04Kategorie
A2

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.

R.1.3

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.

R.1.4

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.

Zapis, który łamie oba kryteria nazewnicze
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.
Ten sam program, zapis spełniający oba kryteria
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 kryteriumGdzie się łamieGdzie jest spełniony
znaczące nazewnictwo funkcji lub metod (kryterium R.1.3)fun w linii 1, nazwa, która pasuje do dowolnego programusortujRosnaco w linii 1, czasownik plus sposób
nazwy zmiennych nic nie znaczą, np. x, a, tab, tablica, funtab i x w linii 1 oraz a w linii 9, czyli trzy z pięciu nazw wymienionych w zasadachliczby, rozmiar i bufor w tych samych miejscach
Wyjątkami od reguły są zmienne bufor, tmp, iteratory pętlii i j w liniach 3 i 5 są poprawne już w tej wersjii 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[] i n, bo tak wyglądają w podręcznikach. tab jest 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 Oceny i oceny są równie dobre; liczy się to, że nie są nazwane Tab.
Java
Szablon klasy generowany przez środowisko wstawia args w 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. self w 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. 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. 2

    Zmienną nazwij tym, co w niej leży, a nie tym, jakiego jest typu.

    wolno tak, bo typ widać z deklaracji, więc tablicaLiczb powtarza informację, którą kompilator już ma, a oceny dokłada tę, której nie ma nikt.

  3. 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. 4

    Zmienną pomocniczą przy zamianie miejscami nazwij bufor albo tmp.

    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 a albo p stoi na liście przykładów po przeciwnej stronie.

  5. 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, oblicz1Zamień na czasownik z dopełnieniem: policzSume
Zmienna nazwana jedną literą poza nagłówkiem pętliPrzemianuj, chyba że litera pochodzi z pseudokodu zadania
Zmienna pomocnicza przy zamianie elementów miejscamiNazwij ją bufor albo tmp
Tablica albo kolekcja nazwana tab, tablica, kolekcjaNazwij ją tym, co w niej leży: oceny, pytania, losowania
Kod gotowy, zostało kilka minut przed oddaniemPrzeszukaj 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.

  1. 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: policzSrednia mówi, co funkcja robi. R.1.4 przepada, i to na jednej nazwie. suma jest znacząca, i jest wyjątkiem wymienionym w kryterium, ale tab stoi 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ą rozmiar i nie zostawiać mu tej decyzji.

  2. 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 x z linii 4, licznik kroków. a i b są bezpieczne, bo zasady oceniania tego arkusza dopuszczają je wprost jako zmienne algorytmu, a tmp jest wyjątkiem wymienionym w treści samego kryterium. x nie ma żadnej takiej ochrony i stoi na liście przykładów. Nazwij go licznikKrokow.

  3. 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, x i a. Iterator i zostaje. 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.

Ani jednej nazwy z listy, a kryterium i tak przepada
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. 1

    Które trzy rodzaje nazw kryterium wymienia jako wyjątki od reguły?

    z pamięci

    Pokaż odpowiedź

    Zmienne bufor i tmp oraz iteratory pętli. Te trzy są wymienione w treści kryterium i powtarzają się we wszystkich przejrzanych sesjach.

  2. 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. 3

    W zadaniu jest pseudokod, w którym tablica nazywa się A. Nazwać ją w kodzie A czy oceny?

    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. 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. 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