[ISO-8859-2]

UWAGI NA TEMAT PROGRAMÓW ZALICZENIOWYCH

DOSTARCZANIE ROZWIĄZAŃ

Decydujące o zaliczeniu i oceniane przeze mnie będzie rozwiązanie, które
dostanę mailem jako ostatnie przed terminem na oddanie zadania.
Oddanie zadania z opóźnieniem do tygodnia powoduje automatyczne odjęcie 50%
punktów, powyżej tygodnia rozwiązanie nie zostanie uznane. To zasady ustalone dla wszystkich grup.

W przypadku, gdy niewielkie opóźnienie jest nieuniknione, proszę wcześniej
mnie zawiadomić i wysłać to, co jest zrobione w "regulaminowym" czasie. Ja
nie chcę być chamem, ale weźcie pod uwagę, że lepsze względy dla wybranej
osoby są krzywdzące dla innych, bardzo chciałbym uniknąć takich sytuacji.
Najlepiej traktujcie te terminy bardzo rygorystycznie, z doświadczenia wiem,
że wtedy też są najlepsze efekty pracy.

PLIKI

Chociaż mówiłem o modułach i zaletach "modularnego" programowania, nie wymagam podziału na moduły w przypadku tych małych programów zaliczeniowych. Jeśli jednak ktoś zdecyduje się na takie rozwiązanie, nie będę protestował. Tylko niech wtedy ten podział będzie sensowny.

Rozwiązania proszę przesyłać jako załączniki do maili. Jeśli jest to kilka plików, niech będą spakowane w archiwum zip, tgz albo tar o nazwie TWOJ_LOGIN.ZIP, na przykład PC176468.ZIP; jeśli jest to jeden plik może być wysłany jako PC176468.PAS. Tak będzie mi łatwiej podczas sprawdzania, ale oczywiście nie będę tego brał pod uwagę przy ocenie.
Jeśli wysyłacie jakiś opis, komentarz do programu, to zróbcie to w osobnym dołączonym pliku (np. readme.txt) a nie w treści listu.

KOMENTARZE

Oczekuję w każdym pliku komentarza na samym początku albo zaraz po wierszu PROGRAM / UNIT. W tym komentarzu powinna się znaleźć informacja o autorze, programie / module. Poza tym krótki opis co program robi (najpierw co a nie jak), jak należy go używać.
Jeśli uważasz, że przydatny dla mnie byłby dłuższy komentarz opisujący działanie całego programu, może on znaleźć się na początku kodu programu (po tym "głównym komentarzu", o którym już napisałem) lub napisz go w osobnym pliku (np. readme.txt).

Oczekuję komentarza opisującego co robi każda niebanalna procedura/funkcja zdefiniowana w programie. W pierwszym programie niech to będzie _każda_ procedura/funkcja. Jeśli program jest podzielony na moduły, koniecznie umieść opis do każdej procedury/funkcji w interfejsie modułu.
W tym komentarzu powino być napisane co znaczy każdy parametr (jeśli nie jest to zupełnie oczywiste), jeśli nie wszystkie wartości parametrów są dopuszczalne, koniecznie napisz o tym. Jeśli procedura/funkcja zmienia wartość zmiennej globalnej, też o tym napisz.

Jeśli działanie programu jest w pewnych miejscach nieoczywiste, skomentuj to w tym miejscu. Ale unikaj komentarzy typu:  a := a+1; { zwiększam a o 1 }, nie o to chodzi, trzeba znaleźć złoty środek.
Jeśli komentarz odnosi się do jakiegoś fragmentu kodu, umieść go przed tym kodem. Można skomentować algorytm, sposób działania jakiejś procedury na początku tej procedury, po komentarzu opisującym co ona robi.

W komentarzach można umieszczać także formuły logiczne, których prawdziwość jest w danym miejscu spełniona, np. niezmienniki pętli, nieoczywisty warunek w jakiejś zagnieżdżonej gałęzi IF/THEN/ELSE itp...

PODZIAŁ NA PROCEURY/FUNKCJE

To bardzo ważna sprawa, aby sensownie podzielić program na fragmenty. Niech to będą jakieś logiczne całości. Jeśli program składa się z kilku faz, to one powinny być procedurami. Jeśli jakąś rzecz robi się dwa razy, tylko z różnymi parametrami, to ta rzecz powinna być procedurą. Pewne standardowe operacje (np. operacje na listach) powinny być procedurami. Myślę, że macie dobrą intuicję...

NAZWY

Niech zmienne globalne, albo te w największych procedurach mają znaczące nazwy, nawet trochę przydługie (ale przecież możliwe też są nazwy krótkie a treściwe). Niech nazwy funkcji i procedur będą znaczące, podobnie typów. Jeśli stosujecie konwencję 'T' na początku nazwy typu, to bądźcie konsekwentni. Zdecydujcie się na polskie albo angielskie, nie mieszajcie ich.

TYPY

Pascal umożliwia bardzo precyzyjne zdefiniowanie typów. Są typy wyliczeniowe i przedziałowe. Zachęcam do ich stosowania. Jeśli da się coś opisać za pomocą typów, to lepiej zrobić to tak niż w komentarzu czy w ogóle. Na przykład jeśli procedura oczekuje parametru z zakresu 0..100, to niech taki będzie typ parametru, a nie Integer z komentarzem {0 <= x <= 100}.

OCENY

Za każde małe zadanie będzie można otrzymać do 5 punktów. Na pewno będę dzielił punkty na 0,5, może 0,25.
Po pierwsze program musi kompilować się i działać zgodnie ze specyfikacją. Małe błędy (brak poprawności) będą owocować odejmowaniem punktów, jeśli program nie działa lub jest poważnie niezgodny ze specyfikcją to oceniam go na 0 punktów.
Program ma być napiany "porządnie", mądrze podzielony na procedury/funkcje i tak dalej.
Program ma być dobrze skomentowany (jak to opisałem) i czytelny.

Życzę powodzenia w pracy nad programami!
	Patryk Czarnik