Poniższe kryteria mają charakter orientacyjny! Starałem się oceniać całościowo – nie tylko na podstawie jednego konkretnego zadania, lecz także uwzględniając ogólne “rozgarnięcie” (oczywiście z korzyścią dla Was!).

W przypadku wątpliwości odnośnie popełnionych błędów bądź chęci ich omówienia – zapraszam na konsultacje (generalnie podczas laboratoriów nie będę omawiał indywidualnych przypadków).

Wyniki kolokwium: kolokwium_2015-16_1_wyniki.pdf

Punktacja za zadania

Błędy krytyczne (-2 p.)

• Zupełny brak znajomości podstawowych konstrukcji i działania podstawowych funkcji języka (np. pętla for, pętla while, funkcja scanf, wywołanie funkcji).
  “Rehabilitacja” (gdy np. ktoś trzy razy pisze daną konstrukcję poprawnie, a raz błędnie) powoduje utratę tylko 1 p.

Błędy poważne (-1 p.)

• Niewłaściwa ilość specyfikatorów konwersji.
• Brak typu zwracanego przez funkcję.
  (Ponieważ wszystkie funkcje na kolokwium zwracały wartość typu int, typ domyślnie zwracany przez funkcje według ANSI, nie był to stricte błąd. Jednak dobra praktyka mówi, aby pisać takie rzeczy explicite).
• Redeklaracja zmiennych, brak deklaracji zmiennej.
• Niezgodność z treścią polecenia (np. brak sprawdzenia działania, zły warunek logiczny powodujący nieprawidłowe działanie (np. == zamiast <=, < zamiast <= itp.), podawanie liczby większej o 10 zamiast mniejszej o 10).

Błędy drobne (-0,5 p.)

• Niezgodność z ANSI C (np. deklarowanie zmiennej nie na początku bloku).
• Brak klamer.
• Brak średnika na końcu instrukcji (gdy notoryczne).
• Pisanie ≤ zamiast <=.

Nie karzę dwa razy za te same błędy związane z brakiem znajomości języka C.

Komentarz prowadzącego:

• Znakomita większość z Was wiedziała jak się zabrać do każdego z zadań. Mieć dobry pomysł – to najważniejsze!
• Pojawiło się sporo błędów składniowych, lecz wiele z nich wynikało z pisania na kartce, bez kompilatora, w warunkach stresu.
• Ilość podstawowych błędów znacznie zmniejszyła się w stosunku do tego, co obserwowałem na laboratorium – to mnie bardzo cieszy
• Nieuważne czytanie poleceń spowodowało u części z Was utratę wielu, wielu punktów… Łącznie, w skali obu grup, aż 1/5 straconych punktów wynikała właśnie z niezrealizowania polecenia!

Wyniki kolokwium: (klik)

Błędy krytyczne (-2 p.)

• Błędna zamiana wartości “w miejscu”.

Błędy poważne (-1 p.)

• Brak inicjalizacji zmiennej przechowującej wartość maksymalną.
• Pominięcie jednej z dwóch pętli sortowania bąbelkowego.
• Niewłaściwe stosowanie operatora dereferencji (*) oraz adresu (&) – np. w niewłaściwym miejscu.
• Brak realokacji pamięci dla tablicy dynamicznej.

Błędy drobne (-0,5 p.)

• Zły zakres losowanych wartości (dla przypomnienia: operator % to reszta z dzielenia, a $\text{mod}(x,n) \in [0,n-1]$).
• Tworzenie tablicy składającej się z 10 elementów, a nie z 11.
• Brak zwolnienia pamięci po dynamicznej alokacji.
• Brak sprawdzenia działania programu.
• Niezgodność z ANSI C.
• Stosowanie tego samego identyfikatora dla zmiennej i funkcji (to błąd składniowy języka C).
• (inne)

Oto arkusz, na podstawie którego będę oceniał projekty: (klik)

Arkusz należy odczytywać w następujący sposób:

• Łącznie za projekt można otrzymać co najwyżej 100% punktów maksymalnej liczby punktów przewidzianych za cały projekt.
• Oceniam projekt pod kątem różnych kryteriów – nie tylko realizacji postawionego zadania, lecz także czytelności kodu czy użycia właściwych elementów języka C.
• Każde kryterium ma pewien udział w całości oceny – udział wyraża się poprzez jego wagę.
• W ramach każdego kryterium istnieją wzajemnie wykluczające się opcje oznaczające stopień realizacji danego kryterium – każda opcja posiada przypisaną ilość punktów.
  Realizacji danej opcji przez daną osobę odpowiada 1 w kolumnie pod odpowiednim numerem indeksu.
  Uwaga: Opis opcji ma charakter orientacyjny, a nie ściśle wiążący!
• Łączny stopień realizacji projektu wyrażony jest przez sumę iloczynów punktów uzyskanych za poszczególne kryteria i ich wag.
• Istnieje możliwość uzyskania dodatkowych punktów za realizację kryteriów w kategorii Dodatkowe, jednak łącznie nie można przekroczyć progu 100% punktów uzyskanych za całość projektu.

Przykład (student o numerze indeksu 123456):
Za kryterium Modułowość na poziomie “żółtym” student otrzymał $0.5 \text{[pkt]} \cdot 0.15 = 0.075 = 7.5\%$ całości punktów. Łącznie za cały projekt student otrzymał 62.5% całkowitej ilości punktów.

Poniżej w możliwie obrazowy sposób przedstawiłem, co rozumiem pod wybranymi kryteriami.

Oto przykład niespójnego nazewnictwa (funkcji):

void wypisz_powitanie();
void calculate_Data();
void wypiszBlad();

Niby wszystkie identyfikatory dość dobrze opisują cel funkcji, jednak mamy tu pomieszanie języków (polski, angielski) oraz sposobu oddzielania członów nazwy.

Spójny system w powyższym przypadku wyglądałby na przykład tak:

void wypiszPowitanie();
void obliczDane();
void wypiszBlad();

Funkcja wypisująca statystyki działania programu składające się z kilku tablic powinna korzystać z funkcji pomocniczej do wypisywania jednej tablicy (a nie zawierać skopiowany kilkukrotnie kod – dla każdej tablicy z osobna).

Poniższy kod nie jest konfigurowalny:

int main()
{
    double masy[3] = {1.2, 3.0, 5.0};
    double sily[3];
    int i;
 
    for (i = 0; i < 3; i++) {
        // Oblicz ciezar danego ciala.
        sily[i] = masy[i] * 9.81;
    }
 
    return 0;
}

…w przeciwieństwie do takiego oto kodu:

#define ILOSC_OBIEKTOW  3
 
int main()
{
    const double PRZYSPIESZENIE_ZIEMSKIE = 9.81;
 
    double masy[ILOSC_OBIEKTOW] = {1.2, 3.0, 5.0};
    double sily[ILOSC_OBIEKTOW];
    int i;
 
    for (i = 0; i < ILOSC_OBIEKTOW; i++) {
        // Oblicz ciezar danego ciala.
        sily[i] = masy[i] * PRZYSPIESZENIE_ZIEMSKIE;
    }
 
    return 0;
}

W poniższej instrukcji:

if (a == 5) {
    ...
} else {
    // pusty `else`
}

fragment z else jest zbędny.

Zbędne fragmenty kodu utrudniają jego zrozumienie oraz zwiększają ryzyko błędu.

Przykładowo, jeśli do rozwiązania danego zadania należy w pewnym momencie wykonać następującą sekwencję operacji:

1. Inicjalizacja pewnej zmiennej X.
2. Wykonywanie pewnych operacji do momentu, aż warunek związany ze zmienną X przestanie być spełniony.
3. “Prosta” zmiana wartości zmiennej X (np. zwiększenie wartości o z góry określoną ilość).

To do dobrych praktyk programistycznych należy użycie pętli for zamiast pętli while.

Oto przykłady zbędnych komentarzy (wbrew pozorom często spotykanych!):

int i = 5;
i++;    //   zwieksz `i` o 1

Natomiast poniższej funkcji obliczającej w szybki sposób wartość $x^{-\frac{1}{2}}$ zdecydowanie przydałoby się kilka zdań komentarza…

float Q_rsqrt( float number )
{
	long i;
	float x2, y;
	const float threehalfs = 1.5F;
 
	x2 = number * 0.5F;
	y  = number;
	i  = * ( long * ) &y;                       // evil floating point bit level hacking
	i  = 0x5f3759df - ( i >> 1 );               // what the fuck? 
	y  = * ( float * ) &i;
	y  = y * ( threehalfs - ( x2 * y * y ) );   // 1st iteration
//	y  = y * ( threehalfs - ( x2 * y * y ) );   // 2nd iteration, this can be removed
 
	return y;
}

To zresztą przykład autentycznego kodu umieszczonego m.in. w silniku graficznym słynnej gry Quake III… – (klik)

…a jeśli chodzi o moje podejście do oceniania: